NFS Mounts werden nach dem Aufwachen aus dem Standby nicht wieder korrekt hergestellt

[jhhh]

Hallo!

Nachdem Ich meinen KDE-Desktop auf OpenSuse Tumbleweed in den Standby-Modus versetze, um ein paar Stunden später genau an der Stelle weiter zu arbeiten, an der ich gerade war, verliere ich alle NFS-Mounts, die einige Ordner mit meinem NAS verbinden (z.B. “/home/jhhh/Archiv”).

Ein kurzes “sudo mount --all” schafft meist sofort Abhilfe.

Trotzdem ärgerlich. Wenn ich daran nicht denke, schreibe ich in die leeren Ordner der Mountpoints.

Ich habe versucht, eine einfache Lösung zu recherchieren - das ist aber nicht sonderlich produktiv: Vieles scheint veraltet oder enthält ellenlange Mount-Einträge, deren Optionen völlig von den “defaults” der mit Yast erstellten NFS-Einträge abweichen.

Kann mir jemand auf die Sprünge helfen?

cat /proc/mounts | grep nfs:

[serverIP]/volume1/Archiv [/path] nfs4 rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,h
ard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=[clientIP],local_lock=none,addr=[serverIP] 0 0

Was ist die moderne “best practice” Option für NFS 4.1 auf OpenSuse Tumbleweed, die nach einem aus KDE heraus initiiertem Standby die NFS Volumes automatisch wieder bereitstellt?

Ach ja, auf eine Abfrage mit showmount -aerhalte ich:
clnt_create: RPC: Program not registered

Vor dem Standby funktionierte das… - Ist das normal oder ein Bug?

Danke schon mal!
jhhh

[hcvv]

Wie das configuriert ist findet man in /etc/fstab. Zeige die doch mal.

Und es wäre auch mal net wenn man am Anfang erwähnt welches openSUSE das ist.

[jhhh]

Hi!

Ok, das ist OpenSuse Tumbleweed - ich hab’s jetzt oben nochmal reingeschrieben.

Die von Yast erzeugten Einträge sehen immer gleich aus:

[serverIP]:/volume1/Archiv /home/jhhh/Archiv nfs defaults 0 0

Hilft das?

De aktuell tatsächlich aktiven “mount” Optionen finden sich in der “grep” Ausgabe oben…

Cheers!
jhhh

[Sauerland]

Ich hab es mal als Schlagwort eingefügt…

[jhhh]

Ah, ok.

Sorry, hab ich übersehen… _OO_/

Danke!
jhhh

[hcvv]

Wenn das sonst funktioniert glaube ich die Eintragung ist richtig.

NFS ist ursprunglich natürlich nicht für Unterbrechungen entwurfen, aber das sollte eigentlich schon längst dafür geeignet sein. Das da mit RPC was schief ist hat mit dein Problem wohl was zu tun.

Ohne eine directe Lösung an zu bieten könnte ich raten um Automount (das richtige) zu benutzen. Dann wird, wenn nötig das Mount gemacht.
Das war früher schon ziemlich einfach zu tun, aber ist jetzt mit systemd um so einfacher. Ein Beispiel (du kannst leicht herausnehmen was bei dir statt defaults übernommen werden soll):

boven.henm.xs4all.nl:/home/wij      /home/wij  nfs   noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.idle-timeout=5min          0  0

Siehe auch:

man systemd.automount
man systemd.mount

Es sind damit schon einige geholfen worden die NFS mount Probleme beim Boot hatten.

---

Übrigens bitte nicht so:

@jhhh

Ach ja, auf eine Abfrage mit showmount -aerhalte ich:
clnt_create: RPC: Program not registered

und dann separat das was herauskommt.

Sondern nur ein copy/paste mit die Prompt-Kommandozeile, alles was kommt, neues Prompt. Wie:

henk@boven:~> uname -r
6.12.0-160000.26-default
henk@boven:~> 

[Sauerland]

https://wiki.debianforum.de/NFSv4-Mini-Howto

Stichwort systemd-automount?

[jhhh]

Alles klar!

Werde ich probieren… (und versuchen, Deine Formatierungs-Empfehlung in Zukunft zu beachten!).

Drei kurze Nachfragen zum Verständnis hätte ich noch:

In dem Link zum Debian Wiki steht, man müsse eine “Systemd Mount-Unit” erstellen… Ist das für den Eintrag in der /etc/fstab noch zusätzlich nötig?

Überschreiben die diversen “timeout” Angaben für Systemd die Option timeo=600der bisherigen “default” Optionen oder kommen die sich ins Gehege?

Verstehe ich richtig, dass die Option noauto das Einbinden nur ganz am Anfang beim Booten abschaltet, danach die Systemd-Einträge aber trotzdem greifen und ausgeführt werden?

Vielen Dank jedenfalls, werde ich alles nachher versuchen, wenn der Rechner hoch und runter gefahren werden kann!

Cheers,
jhhh

[jhhh]

@Sauerland - Danke, hab ich jetzt mal reingeschaut…

Ich frage aber ehrlich gesagt lieber hier im Forum, weil meine Erfahrung mit Rolling Distributionen bisher die ist, dass ich nach einigen Jahren des “Rollings” nicht mehr nachvollziehen kann, welche individuellen Konfigurationen sich durch Entscheidungen der Distributions-Maintainer längst erledigt haben oder sich durch die Umstellung auf andere Subsysteme und Standard-Einstellungen mittlerweile sogar negativ auswirken.

Das ging mir z.B. mal beim BTRFS-Layout für die Wurzelpartition so. Ebenso mit Anpassungen der Belegung zusätzlicher Maustasten und, völlig verheerend, mit meinen Anpassungen an der Skalierung für den Desktop und für einzelne Anwendungen nach dem Arch-Wiki.

Ach ja, die Konfiguration von Sound-Backends und Sub-Systemen sind nochmal so ein ganz anderes und weiteres Minenfeld…

Eigentlich wäre es wirklich schön, eine Übersicht der “Best Practices”-Empfehlungen für Anpassungen an der Konfiguration speziell für OpenSuse zu haben. Einfach um abschätzen zu können, was mit der Vision der Distribution harmoniert und was nicht.

Natürlich ist mir auch klar, dass das unrealistisch ist.

Wer soll das auch machen und auf dem neusten Stand halten?

Das OpenSuse-Wiki ist eigentlich eine gute Anlaufstelle, scheint mir aber auch relativ selten aktualisiert. Viel Arbeit so was…

Beste Grüße,
jhhh

[Sauerland]

@jhhh

In dem Link zum Debian Wiki steht, man müsse eine “Systemd Mount-Unit” erstellen… Ist das für den Eintrag in der /etc/fstab noch zusätzlich nötig?

Schau dir die Zeile von @hcvv an, ansonsten kann dir @hcvv dazu mehr sagen.

[jhhh]

Hab’s schon eingebaut, danke, mach mich gleich ans Testen!

[Sauerland]

Auch lesenswert sind die manpages von mount.nfs und mount.

[hcvv]

@jhhh

In dem Link zum Debian Wiki steht, man müsse eine “Systemd Mount-Unit” erstellen… Ist das für den Eintrag in der /etc/fstab noch zusätzlich nötig?

Systemd benutzt /etc/fstab und erstellt selbst was es braucht.

@jhhh

Überschreiben die diversen “timeout” Angaben für Systemd die Option timeo=600der bisherigen “default” Optionen oder kommen die sich ins Gehege?

Glaube nicht das das irgendwo Probleme gibt. Was ich dir zeige ist schon Jahre in gebrauch ohne welche Probleme.

@jhhh

Verstehe ich richtig, dass die Option noauto das Einbinden nur ganz am Anfang beim Booten abschaltet, danach die Systemd-Einträge aber trotzdem greifen und ausgeführt werden?

noauto verhindert mount beim Boot und bei mount -a. Sonst nichts.
Da dies auch als Lösung für problematische Mounts beim Boot eingezetst wird muß natürlich das mounten beim Boot ausgeschaltet sein. Wie gesagt, es handelt sich um Automount das früher (und jetzt noch immer möglich) über /etc/auto.master configuriert wurde. Mount wenn ein Prozess irgend ein Datei im Pfad anspricht.

[jhhh]

So langsam verstehe ich es!

Habe Deine Zeilen auch schon rein gebastelt - kann sie beim Hochfahren aber erst später testen.

Schade, dass mount -a dann nicht mehr für alles klappt, aber das ist wirklich zu verschmerzen!

Vielen Dank für Deine Hilfe!
jh-hh

[hcvv]

Nochmal dazu als Erklärung.

“automount” wird oft gesagt aber es ist nicht immer Klar was damit gemeint wird.

• automount wie hieroben gemeint.;
• da es als mount Option noauto gibt, gibt es logischerWeise auch auto, also vorerst das automatische Mount at Boot.
• Arbeitsoberfläche Benutzer nennen das Vorgehen beim einstecken eines Mass-storagerät auch “automounting” weil die nicht verstehen um was es sich handelt. Denke Arthur Clarke: “Any sufficiently advanced technology is indistinguishable from magic”.