Samba unter AOS5.1

[P.R.]

Ich vermute mal, dass der config.sys-Eintrag "SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,CONNECTIONS" dafür verantwortlich ist.

Die Autostart Einträge in der config.sys haben auf die SMB Verbindungen an sich keinen Einfluss, das wird vom jeweiligen Programm übernommen. Die automatische Verbindung kann erfolgen, wenn AM-alt/AM-neu oder NDFS gestartet wird.

Damit die Verbindung beim Start der Oberfläche hergestellt wird ist bei AM-neu eine Verknüpfung im Autostart-Ordner nötig. AM-neu, AM-alt und NDFS funktionieren letztlich gleich, haben die nötigen Einträge jedoch anderer Stelle im System (der Autostart Ordner ist ja nicht die einzige Möglichkeit Programme beim Start aufzurufen). Letztlich Geschmackssache. Mir ist die jetzige Lösung angenehmer; lässt sich leichter steuern.

Es poppt ein Dialog auf, der mich zur Eingabe der Passwörter auffordert.

AM-alt/AM-neu/NDFS legen für die zu speichernden Verbindungen eine Konfigurationsdatei an in welcher u. a. der Benutzer plus nötiges Kennwort festgehalten sind. Diese Konfigurationsdateien sind reine Textdateien, das Kennwort wird darin unverschlüsselt gespeichert.

Im Unterschied zu vorher wird das Passwort für den Benutzer aber nicht mehr ohne ausdrückliches zutun gespeichert. Das kann man bei Anlage der Verbindung festlegen oder auch im Nachgang. Der Verbindungsmanger ist die passende Anlaufstelle, siehe Screenshot. Ist ein Kennwort in der Konfigurationsdatei, wird die entsprechende Verbindung ohne weitere Abfrage hergestellt.

Im übrigen kann ich zwischen AM-alt und AM-neu keinen Unterschied feststellen. Die häufig (u.a. von mir) beklagte Instabilität der Samba-Verbindungen hat sich nicht verbessert, ich würde sogar sagen: hat sich verschlechtert.

Zu den Instabilitäten kann ich leider nicht viel beitragen. Abbrüche treten bei mir schon mal auf, aber sehr selten. Wenn mal ein Abbruch entsteht kann ich diesen in der Regel nicht reproduzieren und - ohne Neustart geht dann nichts mehr. Der Grund liegt zweifellos im OS/2, bzw. der SMB Portierung.

Um weiter mit OS/2-Bordmitteln auf meinen QNaps arbeiten zu können, muß ich QTS-Version 4.xxx einsetzen. Ab 5.xxx geht das nicht mehr.

Von meiner NAS Oberfläche bin ich inzwischen ebenfalls ausgesperrt unter OS/2 - auch Synology hat ein modernisiertes System. Ich hatte gehofft, das der Dooble Abhilfe schafft, aber er erweist sich als ziemlich absturzfreudig; damit kann ich nicht wirklich was anfangen.
Rückweg auf das alte NAS System würde zwar OS/2 Zugriff ermöglichen dafür fehlten die für andere Systeme und Anwendungsbereiche nötigen Funktionalitäten; also bleibt es vorerst beim ausgesperrten OS/2.

[DonLucio]

der Autostart Ordner ist ja nicht die einzige Möglichkeit Programme beim Start aufzurufen

Mir schwante schon sowas....

Letztlich Geschmackssache. Mir ist die jetzige Lösung angenehmer; lässt sich leichter steuern.

Seh' ich genauso.

Im Unterschied zu vorher wird das Passwort für den Benutzer aber nicht mehr ohne ausdrückliches zutun gespeichert. Das kann man bei Anlage der Verbindung festlegen oder auch im Nachgang. Der Verbindungsmanger ist die passende Anlaufstelle, siehe Screenshot.

Danke. Problem hat sich damit erledigt.

Zu den Instabilitäten kann ich leider nicht viel beitragen. Abbrüche treten bei mir schon mal auf, aber sehr selten. Wenn mal ein Abbruch entsteht kann ich diesen in der Regel nicht reproduzieren und - ohne Neustart geht dann nichts mehr.

Bis auf dein "sehr selten" beschreibst du damit genau meine Situation. Bei mir aber eben "sehr oft", vielleicht weil ich die SMB-Verbindungen sehr intensiv nutze? Ich habe praktisch alle meine Daten auf der QNap-NAS

Um weiter mit OS/2-Bordmitteln auf meinen QNaps arbeiten zu können, muß ich QTS-Version 4.xxx einsetzen. Ab 5.xxx geht das nicht mehr.

Von meiner NAS Oberfläche bin ich inzwischen ebenfalls ausgesperrt unter OS/2 - auch Synology hat ein modernisiertes System. Ich hatte gehofft, das der Dooble Abhilfe schafft, aber er erweist sich als ziemlich absturzfreudig; damit kann ich nicht wirklich was anfangen.
Rückweg auf das alte NAS System würde zwar OS/2 Zugriff ermöglichen dafür fehlten die für andere Systeme und Anwendungsbereiche nötigen Funktionalitäten; also bleibt es vorerst beim ausgesperrten OS/2.

Auch hier kann ich sagen: Genau meine Situation.
Mit der Ausnahme, dass ich in meiner alten, OS/2-kompatiblen QTS-Version kein Feature vermisse, dass die neueren Versionen hätten. Von daher kann ich die NAS-Administration immer noch per OS/2-Firefox durchführen.
Tja, und Dooble ist leider die große Enttäuschung.


Mit meinen Samba-Problemen werde ich wohl zu leben lernen müssen ... mache ich ja schon seit über 1 Jahr ...

Was ich nur nicht begreife: Wie testen die bei Arca Noae eigentlich ihre Software??? Auch wenn ich geschrieben habe (ähnlich wie du), dass meine Abbrüche nicht zuverlässig reproduzierbar sind, so treten bestimmte Abbruch-Szenarien doch immer wieder auf. Man muß nur mal eine größere Datenmenge lesen / schreiben, über eine gewisse Zeit lang, dann dauert es nicht lange, bis es knallt. Solche Software kann man doch nicht an die Kunden ausliefern!

Gruß,
Lutz W.

[DonLucio]

Also Probleme mit den Abbruch der Smb-Verbindungen kann ich nicht bestätigen. Allerdings - wie schon häufig geschrieben - mache ich das alles mit FC/2.

Ja, ich erinnere mich, wir hatten vor 1 Jahr schon mal so eine Diskussion. Damals wie heute lese ich mit großem Staunen deine Aussage über "keine SMB-Verbindungsabbrüche".

Den FC/2 habe ich zwar auch installiert, habe ihn aber nie richtig benutzt. Das hat historische Gründe: Aus alten DOS-Zeiten war ich den Dateimanager XTree gewohnt und als es den dann in einer OS/2-Version gab (unter dem Namen ZTBold), bin ich dabei geblieben.

Habe ich denn im FC/2 auch solche Abbrüche?
Ich habe mal eine kleine Test-Suite gefahren. 550 Dateien, zusammen 200 MB, vom Samba-Share nach woanders hin kopiert. Einmal mit FC2, einmal mit meinem ZTBold.

Interessanterweise ist der Job mit FC2 dreimal hintereinander fehlerfrei durchgelaufen, während ZTBold 1x abgebrochen ist, kommentarlos, nach ca. 400 Dateien. Ohne aber die Samba-Verbindung dauerhaft runterzureißen.

Auch wenn das nur eine sehr kleine Testreihe ist, läßt das Ergebnis die Vermutung zu, dass "mein" ZTBold irgendwo nicht ganz sauber programmiert ist. Ungeachtet der Tatsache, dass ich seit 20 Jahren, in der Vor-Samba-Zeit, intensiv mit ZTBold gearbeitet habe und *nie* auch nur den kleinsten Fehler hatte.

Aber auch wenn ich daraus den Schluß ziehen sollte, in Zukunft nur mit FC2 und nicht mit ZTBold zu arbeiten, würde das meine Abbruch-Szenarien nicht durchgreifend lösen, denn Abbrüche habe ich ja vor allem bei Anwendungen, wie PMView und verschiedenen Datensicherungsprogrammen, und auch (selbstgeschriebenen) Rexx-Skripten, die letztlich auch nur mit Shell-Aufrufen wie "copy" oder "xcopy" arbeiten. Das Verbindende all dieser Abbrüche ist, dass es sich um das sequentielle Lesen (größerer) Dateimengen handelt.

Andererseits: Andere Anwendungen, wie z.B. OpenOffice, FaxView laufen problemlos... Alles etwas widersprüchlich.

Aber ok, ich werde mal ab jetzt mit FC2 arbeiten statt ZTBold, vielleicht schafft das ja schon eine gewisse Verringerung der Abbrüche.

Danke erstmal,

Gruß
Lutz W.

[eCSBenutzer]

AM-alt/AM-neu/NDFS legen für die zu speichernden Verbindungen eine Konfigurationsdatei an in welcher u. a. der Benutzer plus nötiges Kennwort festgehalten sind. Diese Konfigurationsdateien sind reine Textdateien, das Kennwort wird darin unverschlüsselt gespeichert.

Zumindest im alten NDFS werden/wurden die Passwörter verschlüsselt gespeichert

Ich habe mal eine kleine Test-Suite gefahren. 550 Dateien, zusammen 200 MB, vom Samba-Share nach woanders hin kopiert. Einmal mit FC2, einmal mit meinem ZTBold.
Interessanterweise ist der Job mit FC2 dreimal hintereinander fehlerfrei durchgelaufen, während ZTBold 1x abgebrochen ist, kommentarlos, nach ca. 400 Dateien. Ohne aber die Samba-Verbindung dauerhaft runterzureißen.

Also ich habe meine AOS und ecs-Backups mal alle auf den Qnap kopiert. Kann ja jeder mal in seinem System schauen wieviel Dateien das sind (nein, ich zippe so etwas nicht...). >100000 Dateiein (für mehrere Zeitpunkte). Das dauert zwar, schon mal wegen den Homeverzeichnis vom FF (cache). Aber ohne Abbruch. Was ich allerdings nicht mehr mache war das parallele Kopieren auf den QNap. Da gab es wohl Probleme und durch den erhöhten Verwaltungsaufwand wird die ganze Sache langsamer.
Noch kurz zum Starten des alten NDFS unter eCS. Also mit alt meine ich letzte Version. Ich habe NDFS nie per Config.sys starten lassen (warum auch...) sondern immer nur bei Bedarf über das Programmsymbol. Und da wurden alle Verbindungen gestartet.
Wie das jetzt in AOS5.1 ist muss ich mir noch erarbeiten. Die neue Platte für den Qnap kann ich am Dienstag holen, danach ein Rebuild (mal sehen wie lange das dauert und dann kann ich mit AOS 5.1 weitermachen.

[DonLucio]

Was ich allerdings nicht mehr mache war das parallele Kopieren auf den QNap. Da gab es wohl Probleme ...

Das deckt sich mit meinen Erfahrungen. Ich habe generell den Eindruck, dass das NDFS nicht robust ist in Multitasking- bzw. Multithreading-Umgebungen. Ich habe hier z.B. einen Editor laufen, der - während ich im Vordergrund Text eintippe - im Hintergrund alle paar Sekunden eine Sicherungsdatei schreibt. Auf Dateien, die auf der NAS liegen. Und dabei habe ich schon die seltsamsten Fehlersituationen erlebt. Nicht immer, und schon gar nicht zuverlässig reproduzierbar. Aber auffällig genug.

Das würde für mich auch erklären, warum immer noch - und das zuverlässig reproduzierbar - PMView sich aufhängt. Nicht beim Lesen / Schreiben einzelner Bilddateien, sondern beim Browsen durch ein (großes) Verzeichnis, wofür vermutlich mehrere Threads aufgesetzt werden. Die sich dann im NDFS gegenseitig behindern.

Naja, muß ich wohl mit leben. PMFax kann ja auch einiges und der stürzt nicht ab bei Zugriffen auf Samba.

Gruß,
Lutz W.

[eCSBenutzer]

Mal ein kleines Update, ist zwar weniger für AOS5.1 sondern für NDFS (unter eCS2.1).
Der SMB-Client (3.7.1. vom Juli 2020) kann zumindest lesend auf den QNap 472a zugreifen. Das ist (für mich) insoweit ausreichend, weil der betreffende Hauptrechner als Backup für den Qnap dienen soll. Schreiben funktioniert nicht. Aber das ist (erstmal) nicht wichtig.

[DonLucio]

Der SMB-Client (3.7.1. vom Juli 2020) kann zumindest lesend auf den QNap 472a zugreifen. ... Schreiben funktioniert nicht.

Entschuldige die blöde Frage: Aber du hast schon Schreibrechte deinen Samba-Shares zugewiesen?

Ansonsten wüßte ich nicht, warum Schreiben nicht funktionieren sollte auf deiner Qnap 472a. Da ist doch nix Besonderes an dem Gerät, außer seiner Größe?

Gruß,
Lutz W.

[eCSBenutzer]

Entschuldige die blöde Frage: Aber du hast schon Schreibrechte deinen Samba-Shares zugewiesen?

Natürlich.....

Ansonsten wüßte ich nicht, warum Schreiben nicht funktionieren sollte auf deiner Qnap 472a. Da ist doch nix Besonderes an dem Gerät, außer seiner Größe?

Nun doch..... Wie ich schon schrieb mit eCS2.1 und dem alten NDFS. Unter AOS (neues NDFS) kein Problem. Da spielen die SMB-Versionen mit rein.
Ich hatte ins NDFS von eCS2.1 mal eine Version von AOS reinverpflanzt. Wegen SMB >1. Das ist aber eine tricky Sache weil die Umgebung auch stimmen muss und ich einen Bogen um YUM/RPM mache. Weil ersten "never change an ..." und zweitens das ja nicht mal mit AOS 5.1. (bei mir) funktioniert.
Da ich z.Z. aber die ganzen QNaps umbaue ist dafür erst mal keine Zeit. AOS5.1 kann ja auf den 472a zugreifen. Von daher...

[DonLucio]

Auch von mir mal ein "kleines Update" zu meinen Samba-Erfahrungen:

Ich hatte ja hier schon mehrfach von meinen Samba-Abstürzen berichtet. Sporadische, teilweise auch reproduzierbare, auf jeden Fall häufige Verbindungsabbrüche, bisweilen mit System-Freeze.

Das galt für AOS 5.0.x, hat sich aber unter AOS 5.1 nicht wirklich verbessert.

Nun hat sich ein neues Tor zu möglichen Erklärungen aufgetan:

Seit drei Wochen habe ich die WLAN-Infrastruktur meines Heimnetzes ausgetauscht: Von Telekom-Speedport-DSL-Router, verbunden mit TP-Link-Repeatern und einem D-Link 4fach Switch. Jetzt neu nur noch Telekom-Equipmemt: 1 neuester Speedport-DSL-Router zusammen mit drei zugehörigen Mesh-Repeatern, jeweils mit zwei LAN-Ports.

Ich habe nicht die leisteste Ahnung, wieso diese Hardware-Änderung Einfluß auf die Stabilität von Samba / NDFS haben könnte. Fakt aber ist: Ich habe seitdem (fast) keine Abbrüche mehr. Auch nicht mit dem "alten" Samba aus AOS 5.0.x.

Klingt verrückt, aber so ist es.

Gruß,
Lutz W.

[ehtron]

Hi
das kenne ich aus disks meiner IoT homeautomatisierung. shelly / homeassistant.

da spielt die wlan hardware und auch die mesh configuration, nebst oftmals ahnungloser grund configuration, häufig eine rolle bei connect und stabilitäts problemen.
ist somit nicht ungewöhnlich.

alte regel
für 5ghz und 2.4ghz getrennte, individuelle SSIDs und feste kanal einstellung nach erkundung der umgebung.
oft hilft auch eine feste IP aller im netz befindlichen server.