[gelöst] Verzeichnis von Windows-Server einbinden

[jue]

Ich habe noch bei Jessie mehrere Windows-Verzeichnisse in meinem home nach dem Prinzip home/verzeichnis nach diesem Schema in der fstab eingebunden:

Code: Alles auswählen

//192.168.10.xxx/ordner$  /home/meins/servername/ordner       cifs  defaults,username=meinname,password=supergeheim,file_mode=0777,dir_mode=0777   0   0

Seit dem Upgrade auf Stretch beobachte ich, dass manchmal der Server scheinbar extrem lange braucht, bis er antwortet. Das beobachte ich z. B. mit Dolphin oder Icedove. Eine Zeitlang ist es möglich flüssig zu arbeiten und dann stockt z. B. Dolphin, wenn ich auf ein gemountetes Verzeichnis klicke. Es braucht dann einige Zeit, bis der Ordnerinhalt in Dolphin dargestellt wird. Hat jemand einen Tipp? Ist "file_mode=0777,dir_mode=0777" in der fstab ok?

[rendegast]

Ist vielleicht die firmware für die Netzwerkkarte entfernt worden?

Fehler im 'dmesg'?

Fehler im ip?

Code: Alles auswählen

ifconfig
oder
ip -s link

[jue]

Danke für die Unterstützung.

ifconfig:

Code: Alles auswählen

enp2s0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
        inet 192.168.10.110  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::468a:5bff:fede:a1af  prefixlen 64  scopeid 0x20<link>
        ether 44:8a:5b:de:a1:af  txqueuelen 1000  (Ethernet)
        RX packets 1797  bytes 768090 (750.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1168  bytes 170329 (166.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 290  bytes 23419 (22.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 290  bytes 23419 (22.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ip -s link:

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    23699      294      0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    23699      294      0       0       0       0       
2: enp2s0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 44:8a:5b:de:a1:af brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    827598     2231     0       0       0       159     
    TX: bytes  packets  errors  dropped carrier collsns 
    176842     1242     0       0       0 

Beim Booten kommt auch immer noch diese Meldung:

Code: Alles auswählen

kvm: disabled by bios

Das hat aber wahrscheinlich mit dem Problem nichts zu tun?!? Im Bios habe ich noch keine Möglichkeit gefunden das abzustellen.

[TomL]

Seit dem Upgrade auf Stretch beobachte ich, dass manchmal der Server scheinbar extrem lange braucht, bis er antwortet. ::::::Es braucht dann einige Zeit, bis der Ordnerinhalt in Dolphin dargestellt wird.

Kann es sein, dass die "entfernte" Platte bei Nichtbenutzung einfach nach einiger Zeit in den StandBy-Mode wechselt, weshalb sie bei einem Zugriff erst geweckt werden muss und das das für diese Verzögerung verantwortlich ist?

Ist "file_mode=0777,dir_mode=0777" in der fstab ok?

Das hat keinen Einfluss darauf... das hat den Stellenwert von Fake-News

[jue]

Kann es sein, dass die "entfernte" Platte bei Nichtbenutzung einfach nach einiger Zeit in den StandBy-Mode wechselt, weshalb sie bei einem Zugriff erst geweckt werden muss und das das für diese Verzögerung verantwortlich ist?:

Ja, so fühlt e sich an. Ich habe daher schon beim Administrator angefragt, der weiss aber nichts ...

Ist "file_mode=0777,dir_mode=0777" in der fstab ok?

Das hat keinen Einfluss darauf... das hat den Stellenwert von Fake-News

Jetzt stehe ich aber auf dem Schlauch. Wieso Fake-News? Ich habe irgendwo gelesen, dass "file_mode=0777,dir_mode=0777" in die sources-list geschrieben werden muss und habe es einfach dumm rein geschrieben. Ich bin da absolut nicht kompetent und wollte nur wissen, ob das irgendwie o.k. ist. Bis jetzt hat es auch gut funktioniert. Die Problematik ist erst vor etwa vielleicht 3 Wochen entstanden. Ich überlege halt, ob bei Stretch irgendwas anders ist und es deshalb holpert. Vielleicht geht es ja weg, wenn sich Stretch weiter an Stable annähert.

[TomL]

Ich habe irgendwo gelesen, dass "file_mode=0777,dir_mode=0777" in die sources-list geschrieben werden muss und habe es einfach dumm rein geschrieben.

"sources-list" ??? Das ist jetzt ein Vertipper ...oder? Weil oben schreibst Du "fstab".

Die Parameter beim Mounten haben nur Einfluss darauf, wie lokalen Anwendungen die Rechte angezeigt bekommen oder wie lokale Anwendungen selber die Rechte anzeigen. Das hat aber keinen Einfluss darauf, wie die Rechte auf dem Server wirklich vorliegen oder gesetzt werden. Ein Client-PC kann sich nicht selber die höchsten Rechte mit 777 geben und sich einfach darüber hinwegsetzen, was der Server tatsächlich erlaubt.... das geht nicht. Insofern hat das -abseits von der Wirklichkeit- nur einen Anzeige-Charakter. Ich verzichte bei einem Linux-Server darauf, weil es mir dadurch schwieriger wird, Probleme auf Grund von Zugriffsrechten zu diagnostizieren. Allerdings kann ich nicht 100%ig ausschließen, das Samba nicht doch mehr mit einem Windows-Server kungelt, als mit einem Debian-Server, und ob das nicht vielleicht doch synchronisiert wird. Also, dann würde ich es einfach stehen lassen.

Ich überlege halt, ob bei Stretch irgendwas anders ist und es deshalb holpert. Vielleicht geht es ja weg, wenn sich Stretch weiter an Stable annähert.

Für mich ist das eher weniger ein durch Stretch verursacht Phänomen... ich würde eher hinterfragen, ob sich vielleicht was auf dem Windows-Server verändert hat. Wäre der Server ein Linux-Rechner, würde ich den Zustand der Platten einfach mal mit hdparm checken. Bei Windows weiss ich aber nicht, wie man das macht.

[jue]

"sources-list" ??? Das ist jetzt ein Vertipper ...oder? Weil oben schreibst Du "fstab".

Ja, sorry, eine dumme Verwechslung der Bezeichnungen - ich gestehe: ich war gerade etwas im Multitasking ...
Vielleicht komme ich noch drauf, an was es liegt, dann werde ich es hier mitteilen.

[rendegast]

Du könntest selbst einen samba aufsetzen, zBsp. in einer VM,
und mit dem Tests durchführen.

kvm: disabled by bios

Das zu aktivieren wäre für eine VM von Vorteil.
Gegebenenfalls muß das Laden der Module kvm-amd/kvm-intel und kvm extra veranlaßt werden,
zBsp. Eintrag in /etc/modules oder 'modprobe ...' in einem anderen Startskript.

[jue]

Du könntest selbst einen samba aufsetzen, ...

Ja, oder auch vielleicht auch mit einem Live-System, Knoppix z.B. Mal sehen.
Wenn ich in der Konsole über "ls" im Ordner, in dem die Serverordner eingehängt sind, dran möchte, kommt manchmal:

Code: Alles auswählen

ls: Zugriff auf 'xyz' nicht möglich: Der Rechner ist nicht aktiv

Es sieht irgendwie schon aus, als wäre der Recher abgehängt ...
Wenn ich "ls" mehrmals hintereinander ausführe, kommt wieder alles.
Vielleicht liegt das tatsächlich an diesem Windows-Server.

[jue]

Ich habe immer nioch das selbe Problem.
Eine Weile habe ich die Windows-Freigaben in der fstab auskommentiert und gigolo verwendet. Das hat zuerst einmal scheinbar gut funktioniert und auch das Herunterfahren des Rechners ging rasant (zuvor hat es teilweise ewig gedauert, und es kamen Fehlermeldungen, dass eine Freigabe nicht ausgehängt werden kann. Mit gigolo konnte ich aber nicht mehr problemlos in der Freigabe speichern, besonders Libreoffice machte Probleme, und daher habe ich die Windows-Freigaben wieder in der fstab aktiviert. Jetzt habe ich es weiter beobachtet und meine, dass die Netzwerkverbindung vor dem Aushängen der Freigaben unterbrochen wird. Dadurch fährt der Rechner nicht herunter wie er soll, es gibt Fehlermeldungen. Durch diesen Umstand vermute ich, dass die Problematik irgend wie damit zusammen hängen muss, dass Verbindungen unterbrochen werden. Da es nach dem Starten des Rechners alles einwandfrei funktioniert und die Problematik erst nach einiger Zeit auftaucht, überlege ich mir woran das liegen kann. Die Problematik war bei Jessie nicht vorhanden, sie ist erst mit Stretch aufgetaucht. Wenn jemand eine Idee hat, bitte mitteilen.

[scientific]

netdev in die mountoptionen

[jue]

netdev in die mountoptionen

Danke, das teste ich Morgen, wenn ich wieder am Rechner bin. Müsste dann so aussehen?:

Code: Alles auswählen

//192.168.10.xxx/ordner$  /home/meins/servername/ordner cifs  defaults,username=meinname,password=supergeheim,_netdev,file_mode=0777,dir_mode=0777   0   0

[TomL]

_netdev wird unter CIFS nicht berücksichtigt.

@jue
Versuchs mal auf eine ganz andere Weise... und zwar den Mount-Befehl aus der fstab herauszunehmen und eine eigene Mount-Unit dafür zu verwenden. Das ist möglicherweise der bessere Weg, da systemd sowieso eine generierte Mount-Unit erstellt.... nur eben mit der üblichen Schätzqualität, die nicht zwingend die Verfügbarkeit des Netzwerkes beachtet. Mit der eigenen Unit besteht eine deutlich bessere Möglichkeit, auf die Besonderheiten des Netzwerkes und des Networkmanagers beim Shutdown zu achten. Teste einfach mal, ob das Problem mit der unten folgenden Mount-Unit weiterhin auftritt

Der Name der Service-Unit MUSS passend zum Mount-Point sein. Wenn "meins" nicht Dein tatsächlicher Linux-Name ist, muss Du das hier anpassen und ebenfalls in den entsprechenden Zeilen der der Unit. Die Parameter für "Where", "ConditionPathExists" und Name der Unit müssen zueinander passen ... bis auf "-" für "/":

Code: Alles auswählen

nano /etc/systemd/system/home-meins-servername-ordner.mount

Code: Alles auswählen

[Unit]
Description=Mount Network-Drives

Requires=network-online.target
After=network.target network-online.target
Before=shutdown.target
Conflicts=shutdown.target
ConditionPathExists=/home/thomas/servername/ordner

[Mount]
What=//192.168.10.xxx/ordner$
Where=/home/meins/servername/ordner
 Options=username=meinname,password=supergeheim,rw,nosuid,nodev,noexec,async
#Options=username=meinname,password=supergeheim,defaults,file_mode=0777,dir_mode=0777
Type=cifs

[Install]
WantedBy=multi-user.target

Darüber hinaus empfehle ich Dir, nicht file_mode und dir_mode zu setzen, weil das tatsächlich keinen Effekt auf die wirklichen Rechte serverseits hat. Die dienen nur der Anzeige und erschweren Dir eine Diagnose, wenn irgendwas nicht klappt. Ich würde das erstmal weg lassen. Als weiteren Vorschlag habe ich eine eigene Options-Zeile eingefügt, versuchs mal mit der. Natürlich muss die ganze Unit um die derzeit enthaltenen Pseudo-Parameter bereinigt werden.

Wenn die Unit erstellt ist, eimalig Rechte setzen und aktivieren:

Code: Alles auswählen

cd /etc/systemd/system

chown root:root home-meins-servername-ordner.mount
chmod 644 home-meins-servername-ordner.mount

Das Laufwerk darf jetzt hier natürlich nicht schon gemountet sein:
systemctl start home-meins-servername-ordner.mount
systemctl status home-meins-servername-ordner.mount

Wenn Fehler, dann erst korrigieren, ansonsten für den Systemstart aktivieren:
systemctl enable home-meins-servername-ordner.mount

HTH

[scientific]

Es gibt bei der Gaudi nur ein Problem.
network-online.target stoppt nicht, wenn nm die Verbindung beendet.

Wenn man eine Mount-unit an network-online.target bindet, wird der mount nicht gestoppt, wenn keine Verbindung mehr vorhanden ist. Das ganze System hängt dann wieder, versucht man dann runterzufahren oder auch nur einen Dateizugriff auf den Mountpoint auszuführen.

Hier spielen nm und systemd gar nicht gut miteinander!

Ich hab allerdings auch dafür eine Lösung entwickelt. Die kann ich bei Bedarf späzer posten.

Lg scientific

[TomL]

Es gibt bei der Gaudi nur ein Problem.
network-online.target stoppt nicht, wenn nm die Verbindung beendet.

Was passiert dann? Welchen Einfluss hat das auf den Shutdown?

Für die Mount-Unit kann das imho keine Bedeutung haben. Sobald das Shutdown.target angezogen wird, sollte der Mount wg. "Conflicts" getrennt werden... imho völlig unabhängig davon, ob der NM anschließend noch irgendwas anstellt oder nicht. Der Mount ist also vorher getrennt, bevor der NM das Netzwerk trennen kann, weil der NM imho ja erst durch das shutdown.target über den Shutdown informiert wird... aber dann ist der umount schon durch.

[scientific]

Meine Erfahrung mit div. Ftp-Mounts ist, dass die das ganze System blockieren, sobald die Verbindung unterbrochen wird, und weiterhin blockieren, auch wenn die Verbindung wieder hergestellt ist...

Außerdem müllt es das log zu, wenn die Verbindung weg ist, und leafnode news sammeln will, oder fetchmail versuch mailserver zu erreichen, die nicht erreichbar sind.
Fetchmail und fetchnews laufen bei mir automatisch alle paar Minuten.

Wenn man davon ausgeht, dass ein Rechner nie nicht am Netz ist, hat man sich noch nie mit Laptops beschäftigt, die auch unterwegs verwendet werden.

Wahrscheinlich ist bei dir wieder alles anders, und diese Geschichte uninteressant für dich
Mich störte es, dass ftp-mounts hängen blieben und das System blockierten und dass mir fetch[mail|news] das Log mit Fehlermeldungen über nicht erreichbare Hosts zumüllten.

Ich hab mir network-online.target umgebaut und dem nm ein dispatcher-skript verpasst, dass bei jeder Statusänderung einer Verbindung auf online-sein prüft und in abhängigkeit von diesem Ergebnis network-online.target startet oder stoppt.

Fetchmail.target, fetchnews.target hab ich mit PartOf=network-online.target and dieses target gebunden.
Die fetchmail@$USER.service sind an fetchmail.target mit PartOf= gebunden.
Die Mountunits für ftp-mounts haben eine ähnliche Bindung zu network-online.target.

Bei den Mountunits habe ich die Bindung an ein Automount Target. Ist das Netz da, ist der Automount aktiv. Ist das Netz weg, gibts auf dem Verzeichnis auch kein Automount mehr. Ein ls auf das Verzeichnis liefert ein leeres Verzeichnis und blockiert nicht das System.
Zusätzlich haben solche automounts bei mir noch ein idle-timeout gesetzt und unmounten nach dieser Zeit, wenn sie nicht mehr benötigt werden.

Damit hängt so gut wie nie ein sleep oder shutdown.

Ein ftp-mount benötigt noch einen regelmäßigen Zugriff, sonst hängt der, weil die Verbindung gekappt wird und curlftpfs das nicht mitbekommt. Dazu gibts noch einen timer, der bei aktivem Mount regelmäßig ein stat auf das Verzeichnis loslässt...

Ich finde das Zusammenspiel von nm und systemd mangelhaft.

Lg scientific

[TomL]

Meine Erfahrung mit div. Ftp-Mounts ist, dass die das ganze System blockieren, sobald die Verbindung unterbrochen wird, und weiterhin blockieren, auch wenn die Verbindung wieder hergestellt ist...

Könntest Du noch bitte kurz den Zusammenhang zu meinem Mount-Vorschlag und der Problemstellung erklären...?... ich sehe den gerade nämlich nicht. Zum einen gings hier um einen simplen CIFS-Mount und nicht um eine FTP-Verbindung. Zum zweiten hatte ich ja gesagt, dass der Mount beim shutdown gar nicht blockieren kann, weil er ja getrennt wird, bevor die Verbindung durch den NM getrennt wird. Und drittens, wenn die Verbindung wiederhergestellt wird, impliziert das einen Systemstart, bei dem systemd über die Mount-Unit wieder automatisch mountet... wir sprachen ja zuvor von einem Shutdown... insofern ist auch da kein Blockieren möglich. Und ganz zum Schluß habe ich aus der Problembescheibung nicht verstanden, dass ein volllaufendes Log oder Fetchmail oder der Mailserver das Problem sind.

Ich bin ein wenig ratlos wg. Deiner Aussagen....

Ich finde das Zusammenspiel von nm und systemd mangelhaft.

Ja, da stimme ich Dir zu. Meiner Meinung nach ist das so, weil der NM derzeit noch vollständig nach Wheezy-Regeln arbeitet und sich als "Herr der Netzwerke" aufführt.

[scientific]

Ich gebe zu, dass ich kaum Erfahrung mit smb/cifs-Mounts habe. Wenn ein smb-Verzeichnis auf einen Mountpoint gemountet ist, und die Netzwerkverbindung bricht zusammen (z.B. WLAN hat Interferenzen und baut sich ständig ab und wieder auf) und ich versuche einen Dateizugriff auf eine Datei aus diesem Mountpoint, was passiert dann?
Bei FTP ist es so, dass versucht wird, den Dateizugriff herzustellen, das klappt aber nicht, und dann läuft irgendwann ein timeout ab, und die Verbindung wird unterbrochen. In der Zwischenzeit hängt die Shell, mit der versucht wurde, den Zugriff herzustellen, es hängt das Programm, das gestartet wurde und das versucht, den Dateizugriff herzustellen, die zugehörigen Prozesse sind "defunct" in ps angezeigt, Benutzer, Gruppe und Dateirechte werden mit ls als ???????? angezeigt.

Kille ich curlftpfs mit Signal 9, werden alle anderen Prozesse (shell, Editor...) wieder reaktiv.

Passiert sowas beim Shutdown, hängt eben der Shutdown, bis das timeout abläuft... Und das können schon ein paar Minuten sein. Und so ein Problem hatte doch der OP. oder etwa nicht?

Ich hab ein Szenario beschrieben, wo es mir mit FTP-Mounts gelungen ist, diese Situation zu vermeiden - und welche den Vorteil mit sich bringt, auch andere Dienste in Abhängigkeit einer aufrechten Netzwerkverbindung zu starten und zu stoppen, und so weitere Fehlermeldungen in den Logfiles zu unterbinden.

Noch etwas zum Zusammenspiel von NM und systemd:Networkmanager passt halt vom Konzept her so gar nicht zu systemd. Ob es überhaupt gelingen wird, diese beiden glücklich zu verheiraten, oder ob systemd-networkd die Aufgaben von Modemmanager, wpa-supplicant und Co inklusive graphischem Frontend übernehmen wird, oder ob die beiden bis in alle Ewigkeit so halbert nebeneinander koexistieren werden, wird die Zukunft zeigen...
Networkmanager hat mit seinem Dispatcher schon eine gewisse Funktionalität, wie sie auch systemd bietet... nur halt anders gelöst. Das kompatibel zu machen und dabei abwärtskompatibel zu bleiben, ist sicher eine Herausforderung.

lg scientific

[jue]

@jue
Versuchs mal auf eine ganz andere Weise...

Ja, das mache ich heute. Ich muss halt mit dem Rechner arbeiten und das muss nebenher laufen, d.h. ich brauche ein bisschen Zeit dazu ...
Ich will hier keine blöde Diskussion auslösen, aber wenn ich es richtig begriffen habe, hätte ich dieses Problem nicht, wenn Systemd nicht eingeführt worden wäre. Oder?

[jue]

Hallo Miteinander,
ich habe diese Datei angelegt (Schema):

Code: Alles auswählen

/etc/systemd/system/home-jue-Servername-Freigabe.mount

Der Inhalt der Datei entspricht diesem Schema:

Code: Alles auswählen

[Unit]
Description=Mount Network-Drives

Requires=network-online.target
After=network.target network-online.target
Before=shutdown.target
Conflicts=shutdown.target
ConditionPathExists=/home/jue/Servername/Freigabe

[Mount]
What=//192.168.10.xxx/Freigabe$
Where=/home/jue/Servername/Freigabe
 Options=username=jue,password=geheim,rw,nosuid,nodev,noexec,async
#Options=username=jue,password=geheim,defaults,file_mode=0777,dir_mode=0777
Type=cifs

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

file_mode=0777,dir_mode=0777 

kann ich entfernen, da war ich mir nicht sicher ...
Anschließend

Code: Alles auswählen

chown root:root home-jue-Servername-Freigabe.mount

Code: Alles auswählen

chmod 644 home-jue-Servername-Freigabe.mount

Code: Alles auswählen

systemctl enable home-jue-Servername-Freigabe.mount

Die Freigabe wird eingehängt, jetzt muss ich testen ...
Ich muss das wahrscheinlich für jede Freigabe machen.
Herzlichen Dank an alle für die Unterstützung!
Ich werde berichten, wie sich alles im weiteren Betrieb verhält.
Update: die Freigaben werden eingebunden, es gibt aber noch Probleme.
Beim Kopieren: Zugriff verweigert. Schreiben nicht möglich auf .
Bei LibreOffice: kann nur schreibgeschützt geöffnet und nicht abgespeichert werden.

[TomL]

Stell dir vor, der Server-Admin legt fest, dass der Benutzer 'jue' nur leserechte auf dem Server bekommt. Und stell dir weiter vor, dass der user 'jue' sagt "du kannst mich mal, ich vergebe mir selber mit filemode und dirmode 777 volle Rechte". Glaubst du, dass das möglich ist.... das sich ein Anwender über alles hinwegsetzen kann und sich selber berechtigen kann? Stell dir mal vor, was das für Unternehmen bedeuten würde, wenn jeder Sicherheit und Beschränkungen selber ausser kraft setzen könnte. Ich kann dir zusichern, dass das nicht möglich ist.

Entweder stimmt mit der Anmeldung am Server etwas nicht, so dass du nur als Gast eines 'browsable shares' leserechte hast, oder die Rechte am Server auf den share sind falsch gesetzt.

Wenn die Mount-Unit zum mounten funktioniert, liegt der Fehler 'fehlende schreibrechte' woanders.

[jue]

Stell dir vor, ...

mit den Freigaben in der fstab gab es diese Probleme ja nicht. Also kann es nicht am Server liegen ...
Trotzdem vielen Dank für die Bemühungen, ich freue mich über jeden Tipp ...
Update: ich habe die Freigaben in der fstab wieder aktiviert und es klappt wieder mit dem Speichern ...

[TomL]

aber wenn ich es richtig begriffen habe, hätte ich dieses Problem nicht, wenn Systemd nicht eingeführt worden wäre. Oder?

Nun, ich sag das mal so, nicht systemd ist die Ursache, sondern es offenbart nur die schwächen eines früher statisch und seriell ablaufenden Bootprozesses. Vor dem Hintergrund, dass heute fast überall in der IT die 'Gleichzeitigkeit' der status quo ist, Multiuser, Multitask, Multithread, Multidesktop, Multiwasweissich, setzt systemd das konsequent mit parallelen Start der Prozesse auch beim Boot um. Das führt dann z.b. auch dazu, dass ein Prozess mit Abhängigkeit zum Netzwerk gestartet werden kann, bevor das Netzwerk verbunden ist. Und dann geht so ein Mount leider in die Hose. Das liegt aber nicht an systemd, sondern daran, dass jemand Mechanismen anwendet, die früher gültig waren, jetzt aber nur noch bedingt oder gar nicht mehr.

Wie scientic das auch schon gesagt hat, der NM ist nicht gut auf systemd abgestimmt. Ich halte den sogar derzeit für eine sehr entbehrlich und habe den überall entsorgt.

[TomL]

Update: ich habe die Freigaben in der fstab wieder aktiviert und es klappt wieder mit dem Speichern ...

Bei gleichen (!) mountoptionen? Das kann ich mir grad nicht vorstellen.

[scientific]

Zu nm... Wenn ich einen PC hätte, der am LAN hängt, würd ich den nm auch gegen systemd-networks ersetzen.
Da ich einen Laptop habe, mit dem ich mal per Kabel, mal in verschiedensten WLAN eingeliggt oder schon auch mal mit Surfstick oder gar USB-Thetering ins Netz gehe, ist der networkmanager unverzichtbar.

Da ich sicher nicht der einzige mit diesem Usecase bin, denke ich, wirds hier eine weitere Entwicklung geben, die nm besser mit systemd zusammenarbeiten lässt.

Und wie Tom schrieb, systemd bringt viele und teilweise jahrzehntelang gut gepflegte falsche Konzepte und schlechte Programmierungen gnadenlos zum Vorschein... Die konnte man mit init-Skripten gut umschiffen, aber da waren die immer.

Ein Beispiel ist screen oder tmux, das als userprozess gestartet das ende Einer Session überleben... Was so EIGENTLICH nicht korrekt ist. Denn das Verhalten von initv bedingt, dass man Kopfstände machen muss, um mit dem Ende der Session das HPsystray oder zeitgeist-datahub wieder loszuwerden...

Kille ich ALLE Userprozesse, die in der Session gestartet wurden, bin ich aber auch screen/tmux los...

Jetzt ist systemd der Böse, weil er dieses fehlerhafte Konzept zum Vorschein bringt... Und den selben Fehler mit der falschen Unterstellung machst du auch grad bei den smb-Mounts... Tu es nicht. Lass dich auf systemd ein und lerne, wie man es richtig macht. (bei screen hab ich z. B. Eine schöne Lösung gefunden!)

Lg scientific