staging.inyokaproject.org

Ich habe inzwischen noch etwas über das Problem nachgedacht

• An sich wäre es richtig und sinnvoll, das Aushängen der gemounteten NFS- bzw. cifs-Shares an network.target zu koppeln. Vermutlich ist dies beim normalen Boot-Vorgang auch schon so realisiert (?). Dies scheint aber nicht zu funktionieren, wenn die Netzwerk-Verbindung über einen Netzwerk-Manager hergestellt wurde, da dabei das erforderliche network-online.target gar nicht ausgeführt wurde. Dafür müsste nämlich das NetworkManager-wait-online.service aktiv sein, was aber standardmäßig nicht der Fall ist, denn dieses würde den Boot-Vorgang erheblich verzögern, z.B. wenn die IP-Adresse über DHCP bezogen wird oder gar das Netzwerk gar nicht verfügbar ist. Es bleibt also wohl nur die "Holzhammer-Methode", das Aushängen der Shares an das multi-user.target (entspricht dem bisherigen RunLevel 3) zu koppeln.

• Sollte das Netzwerk beim Shutdown nicht mehr verfügbar sein, führt die Option -f bei umount dazu, dass das Aushängen trotzdem klapt.

• Sollten beim Shutdown noch Anwendungen auf gemountete Shares zugreifen, so werden diese evtl. unschön beendet, was zu deren Absturz führen kann. Bei mir hat z.B. das unschöne Beenden eines Media-Players zu einem Zustand geführt,in dem dann nur noch ein "hartes Ausschalten" möglich war.

• Durch zusätzliches Einfügen der umount-Option -l ("Lazy Unmount")

  umount -a -f -l -t cifs

  wird das Problem nur teilweise behoben. Das Beenden der betreffenden Anwendungen findet dann erst nach dem Aushängen der Shares statt. Es kann dann aber den Shutdown-Prozess wieder bis zum Timeout verzögern. Bei schreibenden Anwendungen kann zudem ein "Lazy Unmount" zu Datenverlusten führen.

Bleibt also festzustellen, dass man deshalb Anwendungen, die auf gemountete Shares zugreifen, unbedingt vor dem Shutdown von Hand schließen sollte. Es handelt sich bei dem von mir vorgeschlagenen Weg deshalb nur um einen Workaround und nicht um eine vollkommene Lösung des Problems.

Für den absolut sicheren Umgang mit kritischen Daten bleibt wohl nach wie vor die Empfehlung aktuell, auf den NetworkManager und ebenso auch auf WICD zu verzichten.

Gruß – Max-Ulrich

Offenbar bestehen keine Bedenken gegen das beschriebene Workaround. Ich werde es deshalb ins Wiki übernehmen.

Für das statische Einbinden beim Systemstart wird in dem Artikel nur ein Eintrag in /etc/fstab oder ersatzweise auch /etc/rc.local vorgeschlagen. Der "Königsweg" für die Zukunft wird wohl auch eher ein systemd Service Unit sein. Um diese Ergänzung bzw. Änderung werde ich mich nötigenfalls später kümmern.

Gruß – Max-Ulrich

Abschnitt „SMB-Protokoll-Versionen“ hinzugefügt; hier alten Abschnitt „SMB2 Support“ als Unterpunkt aufgenommen und neuen Unterpunkt „SMB1 Support“ erstellt. Motivation hierzu ist die geänderte Vorgabe für das SMB-Protokoll in mount.cifs: Ab 17.04 ist SMB-Protokoll 1.0 nicht mehr Standard, sondern muss explizit angefordert werden. Vgl. Wiki zu mount.

Danke, kB! 👍

Mit dem Systemd-Service zum Aushängen der cifs- und nfs-Shares gleich zu Beginn des Shutdown als Workaround zögere ich immer noch etwas. Erstens ist das einfach noch ein bisschen zu früh, da ja vor dem Aushängen der Shares alle Anwendungen geschlossen sein sollten, die noch auf die Shares zugreifen. Und zweitens sind wohl alle Vermischungen von Systemd-Services mit anderen, nicht-Systemd-Befehlen und -Programmen (also z.B. mount und auch NetworkManager) grundsätzlich nicht unproblematisch.

Die Verwendung von systemd bedeutet eine tiefgreifende Veränderung eines Linux-Systems, deren Tragweite mir erst langsam bewusst wird. Da werden noch einige Änderungen oder Ergänzungen im Wiki nötig werden. Zum Beispiel auch im Artikel mount, denn ganz allgemein verhalten sich mittels Systemd eingebundene Partitionen oder Shares anders als "frei" gemountete. Sie können z.B. nicht mittels sudo umount wieder ausgehängt werden … Sie stehen über die ganze Sitzung hinweg unter der Verwaltung von systemd. Und dies gilt sogar dann, wenn systemd implizit über die fstab aufgerufen wurde (Mount-Optionen x-systemd. …).

Aber schimpfen wir nicht über systemd! Ich finde es gut, dass Ubuntu nun einige Alleingänge beendet ( upstart, Unity …) und schrittweise wieder in den sicheren Hafen von Debian zurückfindet.

Gruß – Max-Ulrich

„SMB-Protokoll-Versionen“

ist jetzt auch in

  Distributor ID:	Ubuntu
  Description:	Ubuntu 16.04.5 LTS
  Release:	16.04
  Codename:	xenial

von nöten, sollte also in jedem SMB Beispiel vorkommen

Kann mal bitte ein Samba-Nutzer die Problembehebung aufräumen und insb. den Bezug auf Uralt-Ubuntus rausschmeißen?

12.04 und smbfs entfernt

Beforge schrieb:

Kann mal bitte ein Samba-Nutzer die Problembehebung aufräumen und insb. den Bezug auf Uralt-Ubuntus rausschmeißen?

+1

Ich habe 'mal eine neue Einleitung verfasst und ein paar Links aktualisiert.

In dem Artikel sind noch einige veraltete Aussagen und Formulierungen enthalten, die ich noch gelegentlich schrittweise aktualisieren möchte. Dazu noch ein paar Fragen:

• bei anderen Artikeln ist es nicht üblich, ohne Notwendigkeit bei der Installation noch ",main" anzugeben. Entfernen?

• Das Paket keyutils ist für die Verwendung vom CIFS-VFS nicht nötig. Vermutlich wird es für die Kerberos-Autifizierung (optional) gebraucht. Das muss präzisiert werden.

• Die ciifs-UNIX-Extensions funktionieren bei mir im Protokoll SMBv3 nicht, die Mount-Option unix bzw. posix wird abgelehnt. Dies steht im Widerspruch zu man mount.cifs !

• Alle Empfehlungen mit rc.local müssen weg, weil schon länger deprecated. Alternativ: Eintrag in /etc/crontab unter @reboot

• Der Abschnitt "SMB-Protokoll-Versionen" muss noch überarbeitet und gemäß man mount.cifs präzisiert werden

• Einige (die meisten?) der "Probleme" haben sich wohl inzwischen erledigt. Ich möchte alle "Probleme und Lösungen", die sich auf nicht mehr unterstützte Ubuntu-Versionen (also vor 16.04 LTS) beziehen, löschen. Sollten diese Probleme entgegen den Angaben noch bestehen, bitte hier vermerken!

Ich denke, dass die Aktualisierungen schrittweise "on the fly" möglich sind, und dass dafür keine Baustelle nötig ist.

Gruß – Max-Ulrich

Hallo,

bei anderen Artikeln ist es nicht üblich, ohne Notwendigkeit bei der Installation noch ",main" anzugeben. Entfernen?

Genau. Per Konvention wird mainnicht angegeben, nur die anderen Quellen (als universe, restricted und multiverse).

Alle Empfehlungen mit rc.local müssen weg, weil schon länger deprecated. Alternativ: Eintrag in /etc/crontab unter @reboot

Yup, ist mit systemd veraltet. Noch schöner wäre eine systemd Unit - aber crontab geht auch.

Einige (die meisten?) der "Probleme" haben sich wohl inzwischen erledigt. Ich möchte alle "Probleme und Lösungen", die sich auf nicht mehr unterstützte Ubuntu-Versionen (also vor 16.04 LTS) beziehen, löschen

+1

Ich denke, dass die Aktualisierungen schrittweise "on the fly" möglich sind, und dass dafür keine Baustelle nötig ist.

Kannst du so machen.

Gruß, noisefloor

@noisefloor

Ja, ich frage mich, wie der Artikel "getestet 19.10" bekommen konnte (ich bin unschuldig, ehrlich 😇 ). Manches davon kann so unter 18.04 schon nicht gar mehr laufen!

Gruß – Max-Ulrich

Hallo,

wenn es nachweislich - auch in Teilen - falsch ist, dann kann du die entsprechende Version gerne entfernen. Dann bitte zusätzlich hier Thread posten, was und warum du es entfernt hast. Im Falle von 19.10 ist das konkret jetzt nicht unbedingt nötigt, weil das ja sowie so bald EOL ist.

Gruß, noisefloor

Hi!

Bitte keine Links auf Baustellen bzw. noch nicht existente Artikel setzen! Habe die auf gio mount vorläufig entfernt, die könne, wenn Baustelle/gio mount ins Wiki verschoben ist, wieder rein.

so long
hank

Ok, werde ich künftig beachten.

Damit man die Links dann aber nachher nicht vergisst, kann ich sie ja schon 'mal mit "#" auskommentiert 'reinsetzen, zumindest am Ende, oder? – Im Text geht das natürlich nicht.

Innerhalb einer Baustelle (ist hier nicht der Fall) darf man aber wohl provisorisch auch noch "ungeborene" Links verwenden, wenn man darauf achtet, dass diese spätestens beim Zurückschieben dann funktionieren?

Gruß – Max-Ulrich

Hi!

Ja zu beidem, das Auskommentieren habe ich auch so gemacht.

so long
hank