langes Runterfahren wegen SMB Shares

polyphase

Commander
Registriert
Dez. 2010
Beiträge
2.790
Ich habe seit einiger Zeit das Problem, das mein System lange für das Herunterfahren benötigt.
Nach ein wenig Nachforschung, scheint es an den eingebungenen SMB Shares zu liegen.

Was ich nicht verstehe, ist das dies jetzt erst seit kurzem auftritt. Die Shares sind schon lange eingerichtet.
Mint 21 Cinnamon

Anbei ein Foto des Herunterfahrens:
Shutdown_linux.jpg

Anbei die Konfiguration in der fstab:
Code:
//192.168.x.x/home /home/xx/Shares/home cifs  noauto,users,credentials=/home/xx/.smbcredentials,uid=1000,gid=1000 0 0
//192.168.x.x/Daten /home/xx/Shares/Daten cifs  noauto,users,credentials=/home/xx/.smbcredentials,uid=1000,gid=1000 0 0
 
Das wird irgendwann gepatched. Deshalb konfiguriere ich nicht mein komplettes Netzwerk um 😉
 
Ich würde nicht über die fstab die shares mounten, sondern über den dateimanager mittels gvfs.
 
Was wäre der Vorteil?

Zu meinem Problem, es hatte die ganze Zeit funktioniert und jetzt auf einmal diese Wartezeit beim herunterfahren
 
Bei NFS besteht das selbe Problem. Auch über fstab. Über den Dateimanager muss ich ständig nachm neuen anmelden mein Passwort eingeben, da habe ich und meine Verwandtschaft keine Lust zu. Vor allem ist NFS unsichtbar
Ergänzung ()

Das scheint aber ein Problem vom Netzwerkmanagement zu sein, weil das wohl früher als die Freigaben beendet werden
 
AGB-Leser schrieb:
Das scheint aber ein Problem vom Netzwerkmanagement zu sein, weil das wohl früher als die Freigaben beendet werden
Aha,
aber warum jetzt? Ich habe nichts umkonfiguriert 🤔
 
DU nicht, aber die Entwicklung, weil die die Pakete aktualisiert haben. Hatte ich auch schon oft genug ...
 
Das ist mir klar,
nur wie kann ich das jetzt wieder "zurechtbiegen"?
 
Du kannst das über ein Skript (frag mich jetzt nicht wie) so einstellen, dass zuerst die Freigaben ausgehangen werden und danach erst der Netzwerkdienst beendet wird. Da gibs im Netz Tipps. Ich hab's einfach hingenommen, dass ich manchmal den Rechner nicht sofort ausmachen kann und mich nicht weiter drum gekümmert. Das sollte hier nur ein Denkanstoß in die richtige Richtung sein
 
  • Gefällt mir
Reaktionen: polyphase
AGB-Leser schrieb:
Bei NFS besteht das selbe Problem. Auch über fstab. Über den Dateimanager muss ich ständig nachm neuen anmelden mein Passwort eingeben, da habe ich und meine Verwandtschaft keine Lust zu. Vor allem ist NFS unsichtbar
Was spricht denn dagegen, die Freigabe fest via fstab einzubinden? Die NFS-Shares so konfigurieren, dass nur bestimmte IP-Adressen aus dem lokalen Netzwerk Zugriff haben, dann braucht man auch keine Passwortabfrage.
 
Na so habe ich das ja auch gemacht. Die berechtigten clienten stellt man aber auf'm Server ein. Bei smb habe ich's damals nur einmal gemacht, aber ob die heute auch so bequem wie NFS läuft, weiß ich nicht. Ist ja hier eigentlich auch egal, da es ja ums beenden des Dienstes geht. Probleme gibs übrigens auch, wenn die Freigabe nicht erreichbar ist, weil das Kabel weg ist, oder der Netzwerkspeicher nicht an ist.

Ich habe auch nirgends eine Auflistung der möglichen Einstellungen in der fstab gefunden. Ich komme an den Rechner Grade nicht ran, aber es gibt Einstellungen für solche Fälle. Ich schaue morgen mal nach
 
  • Gefällt mir
Reaktionen: polyphase
NFS hat meiner Meinung nach den großen Nachteil, das es keine Nutzerauthentifizierung gibt.

Somit hat jeder an dem Rechner Zugriff auf das Share.
 
Soll sich mit NFSv4 erledigt haben. Spielt für meinen Einsatz aber keine Rolle, ansonsten hast Du recht. Bei NFS darf der Client auch kein root-Zugriff haben.

Das steht bei mir in der fstab:
C:
[…]nfs    x-systemd.automount,rw,bg,async    0    0
Ist zwar NFS, sollte aber bei smb auch klappen. x-systemd.automount soll den Dateimanager am Einfrieren hindern, wenn die Freigabe erst später zur Verfügung steht. Kannst ja mal testen, vielleicht verhindert das ja den Timeout
Ergänzung ()

Da habe ich das her:
https://wiki.ubuntuusers.de/fstab/#Automount-mit-systemd
 
  • Gefällt mir
Reaktionen: polyphase
Ich glaube ich werde das hier mal versuchen:

Shutdown und Reboot​

Sind beim Shutdown noch SMB-Freigaben eingehängt, so kann sich dieses dadurch um bis zu 120 Sekunden verzögern. Dies ist ein altes Problem (siehe Fehlerberichte 211631 und 1577885) Die älteren Workarounds sind aber wegen der Umstellung auf systemd nun unwirksam. Auch ein Dispatcher-Skript bleibt wirkungslos, da der NetworkManager seit Version 0.9.8 beim Shutdown keine Dispatcher-Skripte mehr ausführt.

Oftmals genügt es, im NetworkManager-Applet die Option "Alle Benützer dürfen dieses Netzwerk verwenden" anzukreuzen. Dadurch wird das Netzwerk früher verbunden und deshalb später wieder getrennt. Führt dies nicht zum Ziel, so empfiehlt es sich, gemountete SMB-Freigaben vor dem Shutdown manuell auszuhängen.

Experten-Info:​

Das Aushängen der gemounteten Freigaben vor dem Shutdown lässt sich durch ein "Systemd Service Unit" z.B. auf folgende Weise automatisieren:
  1. Man verfasst ein kurzes Skript
    #! /bin/sh
    # SMB-Freigaben aushängen
    #
    umount -alf -t cifs
    Dann macht man dieses ausführbar und legt es an geeigneter Stelle ab, z.B. als /usr/local/smb-umount.sh
  2. Dann verfasst man ein Systemd Service Unit
    [Unit]
    Description=UmountSharesAtShutdown

    [Service]
    RemainAfterExit=true
    ExecStart=/bin/true
    ExecStop=/usr/local/smb-umount.sh

    [Install]
    WantedBy=multi-user.target
    und legt dies unter folgendem Pfad ab: /usr/local/systemd/system/UmountShares.service
  3. Nun aktiviert man das Service Unit mit folgendem Befehl
    sudo systemctl enable /usr/local/systemd/system/UmountShares.service
Nach einem System-Neustart ist das Shutdown-Problem dauerhaft behoben, denn die cifs-Shares werden nun immer vor dem Beenden des multi-user.target, d.h. gleich zu Beginn des Shutdown-Prozesses, automatisch ausgehängt.
Quelle: https://wiki.ubuntuusers.de/mount.cifs/
Ergänzung ()

UPDATE:
Das war die Lösung!
Die erste Methode mit dem setzen des Haken in den Netzwerkeinstellungen hat schon gereicht!

smb_shutdown_setting.png
 
Zuletzt bearbeitet:
haha, die Lösung kann so einfach sein. Danke. Leider war das bei mir schon angehakt und funktioniert bei mir nicht
 
  • Gefällt mir
Reaktionen: polyphase
Dann Versuch doch die zweite in der Anleitung mit dem systemd Script
 
Zurück
Oben