Zugriff auf Netzwerkspeicher nach Standby über Nacht nicht gleich möglich

[Dermitlinux]

Ich habe eben den Rechner aus dem Standby von heute früh aufgewacht und konnte mich nicht mit dem NAS verbinden. In der Logdatei sind folgende Einträge:

@Y-Chromosome So hatte ich damals mal begonnen: ohne diese Optionen. Da aber das Problem bestand, versuchte ich mit den Parametern eine Lösung zu finden.
Werde aber mal nur _netdev stehen lassen.

Wenn ich sudo mount -a im Terminal eingebe, kommt zwar keine Fehlermeldung, aber damit kann ich direkt nach dem Standby das NAS ebenfalls nicht verbinden.
Nach ein paar Minuten ging es dann wieder automatisch und das NAS war da.

 

[douggy]

Gib mal in den options explizit die SMB-Version ein, die verwendet wird.

 

[snaxilian]

das ich bevor etwas richtig läuft, oft viel einstellen muss und auch teils an Stellen, die vom logischen Denken her gar nichts mit der Sache zu tun haben sollten aber es doch tun.

Das ist aber viel confirmation bias und Gewohnheitssache. Gib einem langjährigen OS X oder $hier-beliebige-Linux-Distri-einfügen ein Windows an die Hand und dein Satz trifft zu 100% genau so zu. Subjektiv logisch ist oft das, was man einfach gewohnt ist.

@douggy Wurde in #15 bereits gemacht.

@Dermitlinux Ich denke jetzt mal laut und spekuliere: Share funktioniert und wird sauber gemountet aber nach einem längeren Standby ist die Anmeldung nicht mehr gültig. Das System startet wieder, hat ja noch von vor dem Standby den Share gemountet und versucht nur ein Renew der Anmeldung. NAS lehnt dies aber ab, weil abgelaufen. Ein manueller Aufruf des Mounts triggert dann eine vollständige neue Anmeldung.
Ein anderer Gedankengang, falls die DS220j bereits mit DSM 7.x läuft: Mount beim Start probiert der Reihe nach diverse Anmeldetechniken durch bis sich mit dem NAS auf etwas geeinigt wird. Renew nach Standby macht dies nicht bzw. probiert nur den default Wert.
Manpage von mount.cifs nennt leider noch NTLMv1 als default, du könntest also in der fstab noch folgende Option hinzufügen:
sec=ntlmv2
Das ist seit DSM 7.x die Standardmethode zur Authentisierung beim Zugriff auf Shares und wenn man es explizit angibt müssen nicht erst andere Dinge probiert werden...
Eine dritte Möglichkeit, die mir einfällt: Script basteln was beim Start des Standby den Share sauber unmountet und beim Resume wieder mountet

 

[Dermitlinux]

@snaxilian Ich habe noch die DSM 6.2 auf meiner DS220j installiert. Version 7 steht zwar seit langem Bereit. Allerdings berichten viele Nutzer von der DS220j (einer eher schwachbrüstigen NAS), dass das NAS mit der 7er gut zu tun hätte.
Und die 6.2er läuft stabil.
Ich probiere trotzdem mal sec=ntlmv2. Vielleicht klappt es ja. Manuelles Mounten eben mit dieser Option ergab schon mal keine Fehler.

 

[Y-Chromosome]

Das hier liest sich interessant:
https://bbs.archlinux.org/viewtopic.php?id=277722
https://lore.kernel.org/all/87edz63t11.fsf@cjr.nz/T/

 

[Dermitlinux]

Das hier liest sich interessant:
https://bbs.archlinux.org/viewtopic.php?id=277722

Genau. Das hatte ich gestern auch gelesen. Da hatte ich das mit dem vers=2.0 her. So klein ist das Internet :-)

 

[Dermitlinux]

Kurzes Update:
Auch sec=ntlmv2 bringt keine Änderung.
Ich habe zudem folgendes festgestellt:
Es spielt dabei keine Rolle, ob das NAS beim Aufwachen des Linux-Rechners aus dem Standby ebenfalls gerade im Schlafmodus/Standby ist. Das Problem tritt auch auf, wenn das NAS im Standby ist oder eben nicht.
Ist das NAS im Standby und ich rufe einen Ordner über smb://usw. auf (als Lesezeichen in der Dateiverwaltung gesetzt), dann öffnet sich das erste Verzeichnis und das NAS wacht dann auf. Es wird kurz der Laufwerksinhalt geladen und dann ist es online. Das klappt sofort nach dem Aufwachen des Rechners aus dem Standby.

Vielleicht ist es auch einfach nur ein Kernel-Problem, welches in den kommenden Version behoben wird.

EDIT: Ich habe jetzt mal das Laufwerk nicht mit /mnt sondern über /media eingebunden. Werde das testen.


EDIT 31.08.2022
Problem hat sich erledigt. Mittlerweile tritt das Problem nämlich nicht mehr auf. Vielleicht liegt es um Update auf Kernel 5.19.
Danke an alle, die mir geholfen haben!