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

[Dermitlinux]

Hallo,

ich habe einen Netzwerkspeicher (NAS), vom Typ Synology DS 220j, auf denen ich u.a. mit meinem Fedora-Desktoprechner zugreife. Grundsätzlich funktioniert es. Ich habe Zugriff, kann darauf schreiben und lesen. Das einzige Problem gibt es nach dem Aufwachen des Linux-Rechners aus dem längeren Standby. Wenn ich also den Rechner über Nacht im Standby hatte, findet er am nächsten Morgen das NAS nicht mehr sofort. Wenn etwas Zeit vergangen ist, wird das Laufwerk wieder ohne mein Zutun gefunden (Zeit: vielleicht ca 10 Minuten?).

Eingebunden ist das NAS in der fstab wie folgt:

//IP-Adress/gemeinsam /mnt/Gemeinsam-NAS cifs x-systemd.after=network-online.target,_netdev,credentials=/home/aunda/.smbcredentials,user,uid=1000,gid=1000

Dieser Fehler erscheint:

Wenn ich den Rechner nach Herunterfahren neu starte, klappt es sofort.

Im gleichen Netzwerk befinden sich auch noch zwei Windows-Notebooks, (1xWin 10, 1x Win 11). sowie zwei Android-Smartphones. Die Windows-Rechner können sofort darauf zugreifen, auch wenn sie über Nacht im Standby waren. Auch die Smartphones haben sofort am Morgen Zugriff. Das heißt also, dass das NAS grundsätzlich verfügbar ist.

Hat jemand eine Idee, wie ich den fstab-Eintrag anpassen muss, damit es nach dem Standby des Linux-Rechners sofort mit dem Verbinden klappt?

Besten Dank!

System:
Fedora 36 mit GNOME 42.2, Wayland

 

[Sebbi]

mit meinem Fedora-Desktoprechner zugreife.

feste IP oder DHCP ?

 

[Dermitlinux]

Sowohl in den Einstellungen von Fedora als auch in den Netzwerkeinstellungen von dem NAS ist DHCP aktiv (Netzwerkkonfiguration automatisch erhalten). Das habe ich auch nicht geändert, war Standard.

 

[Sebbi]

also NAS mit DHCP finde is persönlich schon sehr schwierig, vorallem wenn die sich mal ändert und andere Systeme noch die alte IP im Cache haben nach dem Standby.

Zusätzlich kannst du ja mal testen, ob Fedora das gleiche Verhalten zeigt, wenn du dem System eine feste IP verpasst.

 

[Pete11]

Ich denke, das liegt eher an den Festplatten im NAS und eventuell an Energiespareinstellungen im NAS. Wenn das NAS erst aus dem Ruhezustand aufwachen muß, kann das schon etwas dauern. 10 Minuten erscheinen mir allerdings etwas lang - 1 bis 2 Minuten können es aber schon sein.

 

[Sebbi]

, das liegt eher an den Festplatten im NAS

das widerspricht aber den Erfahrungen bei anderen Geräten, die keine Probleme haben

 

[snaxilian]

Auch ein "Desktop"-Linux hat /var/log/ und schreibt da seine Logmeldungen rein, das sollte der erste Anlaufpunkt für dich sein bzw. journalctl entsprechend.
https://docs.fedoraproject.org/en-US/quick-docs/viewing-logs/
Nur weil klickibunti Oberfläche "ups" schreibt muss es nicht bedeuten, dass es nicht sinnvolle Fehlermeldungen gibt.

 

[Dermitlinux]

Das NAS muss dabei nicht aus dem Ruhezustand erwachen, da es manchmal schon aktiv ist. Zum Beispiel, wenn ich mit dem Smartphone darauf zugreife. Ansonsten dauert das Aufwachen des NAS aus dem Standby nur wenige Sekunden.
Eine feste IP zu vergeben, traue ich mir nicht zu. Dafür habe ich zu wenig Kenntnisse.
Was vielleicht noch wichtig ist: wenn der Standby nur wenige Stunden war, verbindet sich der Fedora-Rechner sofort mit dem NAS. Das Problem tritt nur auf, wenn er über Nacht im Standby war (also in der Regel über 7-8 Stunden Standby).
Das mit den Logdateien ist eine gute Idee. Ich werde heute Abend wieder den Standby aktivieren und dann morgen mal schauen, was passiert.

 

[kokiman]

Eine feste IP zu vergeben, traue ich mir nicht zu. Dafür habe ich zu wenig Kenntnisse.

Was genau traust du dir da nicht zu? Ich kenns z.b. bei der FritzBox, dass das einfach ein Häkchen ist, da muss man nicht unbedingt auf dem System in einer Netzwerkconfig rumbasteln. Kannst ja mal schauen ob dein Router das auch hergibt.

Bei deinem Problem wäre auf jedenfall die IP der erste Ansatz dem man nachgehen sollte.

 

[Dermitlinux]

dass das einfach ein Häkchen ist,

Ich muss mich entschuldigen, der Haken war bereits gesetzt: "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen."
Ich habe schon ewig nichts mehr am Netzwerk gemacht, das ist mir daher wohl entfallen.

Das ist also schon aktiv, demnach wohl doch kein DCHP für den Linux-Rechner.

 

[snaxilian]

demnach wohl doch kein DCHP für den Linux-Rechner.

Doch natürlich bekommt der PC weiterhin per DHCP seine Adresse. Durch das setzen des Häkchens ist lediglich sicher gestellt, dass er immer die gleiche Adresse bekommt.
Für den PC ist das aber auch eher irrelevant, da dieser nur zugreifender Client ist. Ist denn sicher gestellt, dass das NAS auch immer die gleiche IP bekommt?

 

[Dermitlinux]

Ja, das habe ich eben geprüft. Auch das NAS hat einen Haken bei "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen."

 

[Sebbi]

Ich kenns z.b. bei der FritzBox, dass das einfach ein Häkchen ist, da muss man nicht unbedingt auf dem System in einer Netzwerkconfig rumbasteln.

das ganze mit der festen IP soll dazu dienen zu prüfen, ob das Fedora System nach dem aufwachen nicht einfach die DHCP Adresse vergessen hat und einigen Minuten braucht, um die neu anzufragen von der FritzBox.

Nur den Hacken in der FB zu setzen, das die Geräte immer die gleiche IP bekommen, damit ist der Fehlerdiagnose nicht geholfen.

Auch das NAS hat einen Haken bei "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen."

naja das ist zumindest schon mal ein Anfang, das man ausschließen können sollte, das die IP des NAS wechselt.

Eine feste IP zu vergeben, traue ich mir nicht zu. Dafür habe ich zu wenig Kenntnisse.

ufff und dann ein LinuxSystem nutzen, ein FrickelOS schlechthin. Sorry, aber wenn du dir schon sowas nicht zutraust, solltest du in der Windowswelt bleiben.

https://de.linuxteaching.com/article/how_to_configure_a_static_ip_address_on_fedora das wird unter Fedora 36 auch wohl kaum anders sein

Und ja, ich hoffe mal das du zumindest weißt, was du da einstellen musst so halbwegs.

 

[snaxilian]

ob das Fedora System nach dem aufwachen nicht einfach die DHCP Adresse vergessen hat und einigen Minuten braucht, um die neu anzufragen von der FritzBox.

Guter Ansatz, bin bei den Beschreibungen des TEs davon ausgegangen, dass nur das NAS nicht erreichbar sei, sonstige Netzwerkaktivität aber problemlos funktioniert.
@Dermitlinux Hast du nach dem Standby nur Probleme das NAS zu erreichen aber kannst du die anderen PCs erreichen (z.B. per ping) oder mit dem Browser ins Internet, etc. oder ist allgemein alles 'tot' was per Netzwerk erreichbar wäre?

LinuxSystem nutzen, ein FrickelOS schlechthin

Du meinst dieses "FrickelOS" wo der Mailclient des gleichen Anbieters die Suche des FrickelOS störte? Oder redest du von diesem FrickelOS dessen regelmäßige Patchdays bei gefühlt jedem dritten Mal irgendwas kaputt gehen lassen?
Oder ist das nicht so schlimm weil du bei diesem FrickelOS dich besser auskennst und mit dem anderen nicht so gut umgehen kannst? Ist das jetzt ein Kriterium was ein FrickelOS ist und was nicht?^^

Ich denke wir können uns bequem darauf einigen, dass jedes OS an gewissen Stellen frickelig ist und Vor- und Nachteile hat und dann können wir die Polemik auch direkt sein lassen und persönliche Vorlieben zurückstellen, meinst du nicht auch?

Warten wir mal ab, ob und was der TE in den Logs findet...

 

[Dermitlinux]

@snaxilian Alles andere bezüglich Netzwerk funktioniert. Sofort nach Anmeldung kommt z.B. eine Benachrichtigung vom E-Mail-Programm über neue Mails. Ich kann auch sofort mit dem Browser ins Internet.
Und wenn ich mit smb://.... im Dateimanager auf das NAS zugreife, klappt es ebenfalls gleich. Da habe ich ein Lesezeichen gesetzt, sodass es dann gemountet wird, wenn ich es anklicke.

Neu: Heute morgen klappte der Zugriff nach dem Standby.
Gestern habe ich in der fstab den entsprechenden Eintrag geändert, indem ich _netdev als Option nach vorne gesetzt habe.
Und: ich hatte gestern nach einem Kernelupdate gar keinen Zugriff mehr auf das NAS. Ich musste zusätzlich vers=2.0 als Option in der fstab angeben. Das hatte ich in einem englischen Forum gelesen von einem Nutzer, der seit vorgestern ebenfalls gar keinen Zugriff mehr hatte.

Mal sehen, wie es morgen früh ist.

 

[douggy]

Die beiden Einträge ..

x-systemd.after=network-online.target
_netdev

.. sind doch doppelt gemoppelt? Behaken die sich vielleicht?

 

[Dermitlinux]

Ist vielleicht so.
Der erste sagt "erst verbinden, wenn online" und der zweite sagt, das es sich um eine Netzwerkressource handelt.
Ich werde das erste vllt rausnehmen.
Das Blöde ist nur, dass das Problem immer erst nach längerem Standby auftritt, man also immer erst am nächsten Morgen gucken kann, was sich getan hat.

 

[Y-Chromosome]

Also ich würde an Deiner Stelle mal beide Einträge herausnehmen:

x-systemd.after=network-online.target,_netdev

Nutze auch Fedora und systemd prüft schon bei einem Netzwerkdateisystem wie cifs, ob das Netzwerk hergestellt ist.

 

[snaxilian]

Früher, also vor systemd, reichte _netdev aus und vermutlich hat es sich so eingebürgert beide Optionen zu setzen falls es noch irgendwelche Sonderfälle gab, wo systemd noch nicht half und _netdev weiterhin notwendig war. Afaik braucht/brauchte man _netdev mindestens noch für iSCSI oder generell blockbasierte entfernte Storages aber ggf. klappt das inzwischen auch mit systemd. Ist aber auch etwas her, dass ich mich damit herumärgern durfte.

 

[Sebbi]

Ist das jetzt ein Kriterium was ein FrickelOS ist und was nicht?

FrickelOS heißt für mich, 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 hat Windows den UnixSystemen doch etwas voraus, das es zum größten Teil logisch soweit aufgebaut ist, das man die Einstellungen und Konfigurationen nicht kreuz und quer durchforsten muss, solange Microsoft nicht wieder das UI versucht an Touch etc anzupassen.
Auch das viele Konfigeinstellungen nur in vielen verschiedenen Konfigdateien rumliegen, ist ehrlich gesagt Administratorquälerei.

Die Probleme die du oben beschrieben hast, kommen idR duch Patches, die Lücken schließen sollen aber dafür andere Fehler auslösen. Dies kann auch bei Unix Systemen passieren, die dann denn berühmten KernelPanic verursachen wenn init 1 ausgelöst wird oder so ähnlich.