[gelöst] Verzeichnis von Windows-Server einbinden

[jue]

Hey - vertragt euch - das kann ich nicht brauchen ... freut euch wenigstens, dass ihr meine Probleme nicht habt ...

[TomL]

Das war gut. Mit Libreoffice kann ich wieder schreiben! Danke!

Das ist keine gute Idee. Ich glaube, der LO-Writer kann wohl native Text schreiben, aber ich hätte da kein großes Vertrauen zu. Ich weiss auch nicht, wie der mit cr/lf umgeht.... also ich würde lieber nicht den LO-Writer für solcherlei Arbeiten an Systemeinstellungen nehmen.

Ich empehle Dir, dass Du Dir eine besondere Arbeitsweise angewöhnst... das macht es Dir im Laufe der Zeit einfach mit Debian umzugehen.
1. Grundsätzlich alle normalen Anwendertätigkeiten erledigst Du mit der normalen Anwender-Anmeldung
2. Für allle Änderungen am System meldest Du Dich als "root" an
3. Du machst keine normalen Anwendersachen mit "root"-Rechten
4. Du machst keine Administrationsaufgaben als normaler Anwender, z.b. mit "sudo"

Wenn Du Systemeinstellungen verändern willst, dannn suche nicht nach irgendwelchen grafischen Assistenzsystemen, die sind imho insgesamt bei Linux sowieso nicht so ausgereift wie bei Windows. Aber, das ist die angenehme Kehrseite, es gibt nix effektiveres, als Linuxeinstellungen in kürzester Zeit über das Terminal zu machen....zumindest im Regelfall. Windows ist das selbstfahrende Auto für Dummies, bei Linux muss man selber starten, fahren, lenken , bremsen, denken, gucken, einparken, ausparken... usw *lol* ... Linux ist nicht Windows, aber es ist nicht schlechter als Windows, sondern nur anders.

Installiere Dir zwei Programme, mit denen du fast alles an Administrationsarbeiten erledigen kannst.
- midnight commander
- nice editor

Eine solche Installation ist eine Admin-Tätigkeit, also starte ein Terminal und melde Dich als Admin an. Gib im Terminal

Code: Alles auswählen

su

ein, dann das Password und Du BIST Admin. Nun die beiden Programme:

Code: Alles auswählen

apt-get update
apt-get install mc ne

Wenn die Adminitätigkeit beendet ist, beendet Du die root-sesseion mit "exit", danach bist Du wieder normaler Anwender. Gestartet werden die beiden Programme im Terminal mit mc oder ne. Im normalen Terminal mit nur Anwenderrechten, nach vorheriger root-Anmeldung (s.o.) mit root-Rechten.

Der Midnight-Commander ist ein effektiver Dateimanager und der Nice Editor ist ein leicht und fast intuitiv zu bedienender Editor, In beide muss man sich aber ein wenig einarbeiten. Guckstu z.B. hier:http://ne.di.unimi.it/docs/index.html. Man kann den ne relativ leicht auf seine eigenen Bedürfnisse umbauen, so dass die gewohnten Tastenkombinationen auch im Terminaleditor funktionieren.

Hey - vertragt euch - das kann ich nicht brauchen ... freut euch wenigstens, dass ihr meine Probleme nicht habt ...

Keine Sorge, hier gehts eher gesittet zu.... ein bisschen Grummeln mit der Ungeduld der Kinder und dann ist wieder alles OK

Hth

[jue]

Das war gut. Mit Libreoffice kann ich wieder schreiben! Danke!

Das ist keine gute Idee. Ich glaube, der LO-Writer kann wohl native Text schreiben, ...

Ich habe mich vielleicht nicht präzise ausgedrückt. Mit "schreiben" meinte ich z. B. ein odt-Dokument in der Freigabe öffnen, bearbeiten und speichern. Das "speichern" war das "schreiben" auf die Platte.

[jue]

Also, ich möchte es pragmatisch einmal anders versuchen. Wenn ich gvfs/gigolo für den Zugriff auf die Freigaben verwende, habe ich ja im Gegensatz zu den anderen Lösungen nur ein einziges Problem. (Ich vermute, dass es auch daran liegt, dass ich die Freigaben auch aushänge, wenn ich sie nicht benötige oder bevor ich den Rechner herunter fahre.) Beim Speichern z. B. eines odt-Dokuments bekomme ich aber die Nachricht "Fehler KIOExec". Wenn ich das in den Griff bekommen würde, wäre ich schon zufrieden ...

[scientific]

Ach komm, Tom... Du deklarierst, es gehört nicht dazu, dann ist es so.
Akzeptiere ich aber nicht. Denn MEINE Erfahrung zeigte, dass an anderer Stelle eine ganz ähnliche Geschichte ist... Die zu lösen bringt auch fürs Ursprungsproblem die Lösung.
Ich nenne es Querdenken, du nennst es wohl Querulieren...

Btw,_netdev ist eine vom filesystem unabhängige Mountoption. Daher hast du die auch nicht in der cifs-Manpage gefunden. Ist diese Option in den Mountoptionen, wird eine Abhängigkeit zu remote-fs.target hergestellt. Dieses wiederum wird erst nach network.target gestartet. Damit wird ein Filesystem erst gemountet, nachdem das Netzwerk steht, und ausgehängt, bevor das Netzwerk runtergefahren wird.

Lt. Deinen Erläuterungen ist das aber alles nicht relevant und nur lästige Nebenschauplatzdiskussion...

Egal. Geh ich halt nicht mehr auf dein Geschreibsel ein. Mach dein Zeugs, wie du willst.

Ich poste meine Lösungen gerne. Wer das Zeugs dazu hat, sich diesen Lösungen anzunähern, sei gerne willkommen. Ich versuche so portable und im Endeffekt komfortabelste Lösungen zu entwickeln, wie nur möglich. Und ich geb zu, da steckt teilweise richtig Hirnschmalz drin, um es so zu lösen, wie ichs tu. Dafür reicht dann aber meist wirklich ein wenig copy&paste, da ich es so universal wie mir möglich mache. Wenn es dir zu mühsam ist, dahinterzusteigen und Zusammenhänge zu erkennen... Dann soll es so sein. Du hast ja offenbar genug Zeit darüber nachzudenken, warum meine Angebote zu kompliziert und unnötig sind.

Lg scientific

[TomL]

Ach komm, Tom... Du deklarierst, es gehört nicht dazu, dann ist es so.

Nein, es liegt daran, dass Du wiederholt Aussagen raushaust, die nix mit der Realität zu tun haben und verursachst damit diese dämlichen Nebendiskussionen, die das Problem nicht lösen, sondern die Lösung eher erschweren... wie Dein folgender Absatz, der einfach nur falsch ist. Bevor Du angepissst solche Klamotten raushaust, mach doch erst mal Deine Hausaufgaben....

Btw,_netdev ist eine vom filesystem unabhängige Mountoption. Daher hast du die auch nicht in der cifs-Manpage gefunden. Ist diese Option in den Mountoptionen, wird eine Abhängigkeit zu remote-fs.target hergestellt. Dieses wiederum wird erst nach network.target gestartet. Damit wird ein Filesystem erst gemountet, nachdem das Netzwerk steht, und ausgehängt, bevor das Netzwerk runtergefahren wird.

1. _netdev ist viel älter als systemd, das gabs schon viel früher.
2. _netdev als direkter Parameter ist ohne jeden Zweifel FS-abhängig, man kann das einfach im Source-Code der Mount-Helper nachsehen
3. das _netdev auch von systemd beachtet wird, um ggf. in der Funktion mount_needs_network() true zurückzugeben, ist trotzdem völlig belanglos, weil systemd sowieso vor dem Mount in der Funktion fstype_is_network() feststellt, dass CIFS eine Netzwerkressource ist. Man kann das mit _netdev machen, ist aber völlig unnötig und hat effektiv für den Mount-Helper sowieso keine Bedeutung, sondern nur eine indirekte für die Platzierung der Mount-Unit, was aber auch wieder völlig belanglos ist.....
4. ... weil sogar freedesktop selber auf seiner Man-Page feststellt, dass aus network.target in keinster Weise abgeleitet werden kann, dass das Netzwerk tatsächlich vollständig etabliert ist.

"Running Services After the Network is up
So you have configured your service to run after network.target but it still gets run before your network is up? And now you are wondering why that is and what you can do about it?"
https://www.freedesktop.org/wiki/Softwa ... orkTarget/

Es funktioniert (vielleicht) das, was ich vor mehreren Postings schon mal gesagt habe, und zwar das Netzwerk über systemd-network starten und dann auf systemd-networkd-wait-online.service warten. Das hat aber andere Nachteile.

Eigentlich ist doch alles gesagt, Du solltest es vielleicht einfach dabei belassen.... oder, was noch besser wäre, mach doch einfach einen in sich geschlossenen Vorschlag zu Lösung des Problems, von Anfang bis Ende, komplett durch. Davon haben alle was. Und Du solltest mal begreifen, dass es hier nicht um Konkurrenz geht, wer die beste Lösung hat, sondern einfach nur um die pragmatische Beseitigung von Problemen.... an dumme Wettbewerbe beteilige ich mich nicht.

Egal. Geh ich halt nicht mehr auf dein Geschreibsel ein. Mach dein Zeugs, wie du willst.

Dieser Stil ist mehr als fragwürdig und zeugt weder von notwendiger Distanziertheit, noch von Reife... das hier ist NUR ein Forum ... für mich ein Zeitvertreib.....

[scientific]

So. Mein letzter Beitrag. Lies das, mach dir Gedanken dazu, oder lass es bleiben.

https://unix.stackexchange.com/question ... fstab-work

Tom, du magst nett sein, aber das was du von dir gibst, zeigt mir, dass du sehr starr in deinen Gedanken bist.

Leb wohl.

[jue]

Oh Manoman, ihr beide seid wirklich prädestiniert mir zu helfen ...
O.k. ich pfriemle nächste Woche _netdev in meine fstab.
Jetzt ist aber zuerst einmal Wochenende. Entspannt euch. Lasst es euch gut gehen.
Wenn noch jemand eine Idee zu gvfs/gigolo hat: gerne, ich würde mich freuen ...

[TomL]

Tom, du magst nett sein, aber das was du von dir gibst, zeigt mir, dass du sehr starr in deinen Gedanken bist.

Nein, bin ich nicht... hier gibts nur eine einzige Erkenntnis, und zwar die, dass Dich Fakten einen Dreck interessieren. Hier im Thread gings um einen CIFS-Mount und um systemd. Beim ersteren (direkt über den Mount-Helper) wird _netdev in Zeile 751 einfach ignored:
https://git.samba.org/?p=cifs-utils.git ... b531d858e6

Beim zweiten ist das Ergebnis mit oder ohne "_netdev" absolut identisch, wie man im systemd-Code-Block eindeutig sehen kann. Das heisst, bezogen auf das von Dir gewünschte Resultat hat _netdev oder nicht _netdev absolut keine Auswirkung, das Resultat ist mit oder ohne das gleiche, wie ich oben schon mal festgestellt habe:
https://github.com/systemd/systemd/blob ... re/mount.c
ab Zeile 73 im Zusammenhang mit
https://github.com/systemd/systemd/blob ... unt-util.c
ab Zeile 528.

Man kann sich auch relativ einfach von Systemd die Abhängigkeiten anzeigen lassen, hier eine von systemd erstellte Grafik über den fstab-CIFS-Mount ohne _netdev,

Die Ausgabe ist mit oder ohne Parameter identisch.... der Parameter ändert absolut gar nichts, weder in der Theorie, noch in Echt, siehe eben auch Source-Code-Auszüge Die einzig relevanten Abhängigkeiten sind network.target und network-online.target... aber zu beiden sagt die Man-Page, dass daraus nicht abgeleitet werden kann, dass das Netzwerk-Ziel auch tatsächlich erreicht werden kann, sondern nur, dass das Netzwerk gestartet wurde und sich in einem quasi beliebigen Status auf dem Weg zur fertigen Verbindung befindet. Aber offensichtlich interessieren Dich Fakten überhaupt nicht, sondern eher das beleidigte Nachtreten.

[scientific]

Ach TomL, lass es gut sein.
Du versteifst dich so sehr in deinen Bemühungen mich zu widerlegen und schlecht zu machen, dass die gar nicht aufgefallen ist, dass ich schon einen Service gepostet habe, der dazu geeignet SCHEINT, eine funktionierende Netzwerkverbindung abzuwarten...

NetworkManager-wait-online.service

Und Pfiati

[jue]

... und um mein Problem kümmert sich hier niemand ...
vielleicht zur Erinnerung, mein primäres Problem: ob ich die Freigaben in die fstab einbinde oder mit den Mount-Units in /etc/systemd/system/ arbeite, nach einer Weile - 1 Stunde oder so - kann ich nicht mehr auf die Freigaben zugreifen und der verwendete Dateimanager friert gewissermassen ein. Wenn ich dann die Freigaben mit gigolo einhänge, kann ich darauf zugreifen obwohl der Dateimanager immer noch hängt. Damit kann ich aber geöffnete odt-Dateien nicht mehr speichern. Das zweite Problem ist, dass der Rechner nicht herunter fahren will, weil die Freigaben nicht ausgehängt werden können. Nur wenn ich die Freigaben in der fstab auskommentiere oder die Mount-Units in /etc/systemd/system/ lösche und nur gigolo dazu verwende auf die Freigaben einzubinden und sie wieder vor dem Herunterfahren aushänge, geht auch das Herunterfahren schnell und ohne Probleme.

[scientific]

Doch.

NetworkManager-wait-online.service

Zum 3. Mal in diesem Thread.
Füge das in die Mount-Unit als

Code: Alles auswählen

 
After=NetworkManager-wait-online.service

ein. Das könnte Abhilfe schaffen.

Aber Achtung, das könnte deinen Bootvorgang auch massiv verzögern wenn die Netzwerkverbindung nicht rasch stabil aufgebaut werden kann!

Lg scientific

[jue]

Füge das in die Mount-Unit als

Code: Alles auswählen

 
After=NetworkManager-wait-online.service

ein.

Ja, Danke, das versuche ich nächste Woche, obwohl ich es nicht verstehe ...

[TomL]

....arbeite, nach einer Weile - 1 Stunde oder so - kann ich nicht mehr auf die Freigaben zugreifen und der verwendete Dateimanager friert gewissermassen ein. Wenn ich dann die Freigaben mit gigolo einhänge, kann ich darauf zugreifen obwohl der Dateimanager immer noch hängt. Damit kann ich aber geöffnete odt-Dateien nicht mehr speichern. Das zweite Problem ist, dass der Rechner nicht herunter fahren will, weil die Freigaben nicht ausgehängt werden können.

Das ist alles völlig normales Verhalten, wenn die Verbindung zum Server wegfällt. Da im Betreff "Windows-Server" steht, kann das hier die Ursache sein... du müsstest mal prüfen, ob die Windows-Policies vielleicht ein hierzu passendes Default-Setting haben. Wenn ja, ist der Server das Problem, nicht der Linux-Client. Debian trennt m.E. nach einer abgelaufenen Zeit nicht irgendwelche Verbindungen.
https://technet.microsoft.com/en-us/lib ... 11%29.aspx
Aber das sind zwei verschiedene Baustellen... zum einen der Mount beim Systemstart und der dazu passende störungsfreie UMount beim Shutdown. Und als zweites die wegbrechende Verbindung.

@Scientic, Du nimmst Dich ein wenig zu wichtig... ich habe nicht den geringsten Ehrgeiz, Dich zu widerlegen und noch weniger, dich schlecht zu machen... ich beschäftige mich ausschließlich mit Fakten und Argumenten, und im Gegensatz zu Dir nicht mit Personen. Und ob Du das geschrieben hast oder das Sandmännchen oder Wonderwoman macht für mich keinen Unterschied.... ist alles nur ein Text auf dem Monitor, mit dem ich mich befasse.

[scientific]

Ach TomL... Ach Ach...

Meine unnötigen Exkurse haben allerdings auch den Hinweis zu Tage gefördert, dass ich für einen blöden FTP-Mount, der eine Autotrennung nach einer gewissen Idle-Zeit eingebaut hat, die ich nicht beeinflussen kann. Diese hat zur Folge, dass curlftpfs beim Shutdown auf eine Reaktion des FTP-Servers wartet, diese aber nicht bekommt, und daher eine massive Verlängerung der Shutdownzeit von 2-3 Minuten verursacht.

Dieser unnötige Hinweis, weil ein FTP-Server ja kein Windowsserver ist und da sowieso immer alles anders ist und überhaupt und sowieso und Fakten sind eh auch nur Fakenews und alternative Fakten...

Nun... Um diese Zwangsbeendigung mit nachfolgendem Hänger bei Shutdown oder Sleep zu umgehen, hab ich mir eine systemd-Unit (Kombination aus timer und service) gebaut, die gestartet wird, sobald der FTP-Mount aktiv wird und die regelmässig ein stat auf das Verzeichnis loslässt. Und die auch wieder beendet wird, wenn das Verzeichnis geunmountet wird.

Ich hab auch nach Interesse gefragt, ob ich den Code dieser beiden Units posten soll, und wie man sie verwendet.
Daher jetzt noch mal die Frage... soll ich? Interesse?
Diese Units könnten nämlich auch eine serverseitige Trennung vom Windowsserver verhindern, wenn dieser so eingestellt ist, dass nach einer idle-Time die Verbindung unterbrochen wird.

Nein. Ich poste das gleich.

Code: Alles auswählen

(0 ✓) root@aldebaran[/@debian-testing] (00:01) /etc/systemd/system: # cat ftp-keepalive@.timer 
[Unit]
PartOf= %i.mount
After= %i.mount
Before=umount.target
Conflicts=umount.target sleept.target suspend.target

[Timer]
OnActiveSec=10
OnUnitActiveSec=90

[Install]
WantedBy=%i.mount

Code: Alles auswählen

(0 ✓) root@aldebaran[/@debian-testing] (00:01) /etc/systemd/system: # cat ftp-keepalive@.service 
[Unit]
#Description=Keepalive FTP-Connection on %f

[Service]
#ExecStart=/bin/sh -c "/bin/ls %f > /dev/null"
ExecStart=/bin/sh -c "/usr/bin/stat %f > /dev/null"

Du kannst für jeden Mountpunkt (unabhängig ob über fstab oder explizite systemd-unit gehandhabt) extra dieses keep-alive-Timer aktivieren, indem du den Timer (nicht das Service!!!) enablest:

Code: Alles auswählen

systemctl enable ftp-keepalive@home-username-mount-point.timer

Stör dich jetzt nicht am Namen der Unit "ftp-keepalive". Ich hab die für ftp-Mounts im Einsatz, aber da nur regelmäßig nach dem Mounten ein stat (oder wenn du im Servicefile das stat kommentierst und die Zeile mit ls freigibst, dann wird ein ls statt einem stat gemacht) abgesetzt wird, um dem Server zu zeigen, der Mountpoint wird verwendet.

Noch eine Anmerkung. Ich verwende für solche Mounts gerne Automounts mit automatischem Unmounten nach einer gewissen Zeit der Nichtbenutzung.

TomL hat das zwar als unnötiges Abschweifen tituliert... aber ich bin überzeugt, dieses Verhalten wird dir Jue helfen, dein Problem einzugrenzen oder gar zu lösen.

Wenn du Automount verwendest, dann wird der Samba-Mount nicht beim Systemstart gemountet, sondern erst dann, wenn du das erste Mal darauf zugreifst.

Eine solche Automount-Unit könnte so aussehen:

Code: Alles auswählen

root@aldebaran[/@debian-testing] (00:02) /etc/systemd/system: # systemctl cat home-jakob-xundeenergie.at.automount 
# /run/systemd/generator/home-jakob-testmount.automount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Automount]
Where=/home/jakob/testmount
TimeoutIdleSec=20s

Diese Automountunit kommt direkt aus der /etc/fstab wo die zugehörige Zeile so aussieht:

Code: Alles auswählen

curlftpfs#meinloginusername:strenggeheimesftppasswort@ftp.server.example/ /home/jakob/testmount fuse x-systemd.automount,noauto,x-systemd.idle-timeout=20,nofail,x-systemd.device-timeout=2,uid=scientific,gid=scientific,allow_other	0	0

Die fstab musst du halt auf deinen Cifs-Mount umlegen (was soviel bedeutet wie die beiden Mountoptionen x-systemd.idle-timeout=20 und x-systemd.automount sowie noauto einfügen)
Für korrektes Funktionieren muss die idle-timeout niedriger sein als das Intervall in dem stat abgesetzt wird (in der Unit ftp-keepalive@.timer der Wert . Warum?
Wenn nach 60 Sekunden ohne Zugriff das Verzeichnis ausgehängt wird, aber alle 40 Sekunden ein stat kommt, wird das Verzeichnis nie ausgehängt.

Vielleicht hilft dir ja mein unnützes, faktenfreies Geschwafel. Hier tut es jedenfalls gute Dienste.

Noch ein letzter Hinweis!
Mit Kernel 4.11 aus experimental klappt der Automounter mit Gnome nicht mehr. Es wird ständig gemountet, sobald ein Verzeichnis ausgehängt wurde. Bis Kernel 4.10 funktioniert es allerdings wunderbar mit dem Automounter. Einen Bugreport dazu hab ich schon geschrieben.

lg scientific

[scientific]

Füge das in die Mount-Unit als

Code: Alles auswählen

 
After=NetworkManager-wait-online.service

ein.

Ja, Danke, das versuche ich nächste Woche, obwohl ich es nicht verstehe ...

Das ist ein Service, der von network-online.target aufgerufen wird. Wie TomL schon schrieb, garaniert network-online.target nicht, dass eine Verbindung steht, sondern signalisiert nur, dass der Aufbau einer Verbindung gestartet wurde.

Code: Alles auswählen

# cat /lib/systemd/system/NetworkManager-wait-online.service 
[Unit]
Description=Network Manager Wait Online
Documentation=man:nm-online(1)
Requisite=NetworkManager.service
After=NetworkManager.service
Before=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30
RemainAfterExit=yes

[Install]
WantedBy=network-online.target

Dieses Service ruft das Programm nm-online auf, welches sich mit Returncode 0 (=Erfolg) beendet, sobald der Networkmanager eine erfolgreiche Verbindung aufgebaut hat. Passierte das nach 30 Sekunden immer noch nicht, beendet sich das Programm hier mit einem Fehlercode.
Der Service wird mit dem Type=oneshot ausgeführt. Das bedeutet, die von ihm abhängigen Units werden erst gestartet, sobald das Programm in ExecStart sich beendet hat.
Das wiederum bedeutet, dass eine Mountunit, welche die Abhängigkeit

Code: Alles auswählen

After=NetworkManager-wait-online.service

hat, erst nach dem beenden dieses Services (also wenn eine erfolgreiche Verbindung mit dem Netz gemeldet wird) gestartet wird.
Du kannst natürlich noch zusätzlich

Code: Alles auswählen

Wants=NetworkManager-wait-online.service

in deine Mountunit einbauen. Da müsst man jetzt experimentieren, ob das notwendig ist. Wahrscheinlich schon.

Verwendest du den Automounter, wie im Posting von mir von vorhin vorgeschlagen, dann müssen diese beiden Wants, und After-Abhängigkeiten natürlich in die automount-Unit, nicht in die Mountunit.

Ich müsst jetzt auch noch experimentieren, dass ich dir eine letztgültige Anleitung geben könnte... Aber ein wenig experimentieren bringt eigene Lernerfolge und mehr Verständnis.

lg scientific

[TomL]

Vielleicht hilft dir ja mein unnützes, faktenfreies Geschwafel. Hier tut es jedenfalls gute Dienste.

Was soll dieser Scheiss? Warum eskalierst Du das immer und immer weiter und projizierst das hier völlig unnötig und zusammenhanglos auf einen neuen und eher konstruktiven Sachverhalt? Warum kannst Du nicht einfach mal das Nachtreten lassen und aufhören, einen Disput regelrecht weiter zu forcieren?

Beschränke Dich Doch einfach mal auf die sachliche Ebene..... wenn etwas funktioniert, kann es nicht komplett falsch sein. Und wenn etwas funktioniert, ist das nicht "faktenfrei", sondern der Status Quo "es funktioniert" ist der Fakt. Was soll das also?

[scientific]

Ich schrieb dies schon früher in diesem Thread, du hast es als unnötiges Abschweifen abqualifiziert.

Egal.

[jue]

1. Schritt:
Ich habe jetzt in /etc/systemd/system/ in den *.mount-Dateien

Code: Alles auswählen

After=network.target network-online.target

durch

Code: Alles auswählen

After=NetworkManager-wait-online.service

ersetzt. Der Bootvorgang kommt mir gleich vor, also er braucht nicht länger. Die Freigaben sind erreichbar.
Ich teste jetzt und fahre dann bei Bedarf mit dem 2. Schritt weiter.

Code: Alles auswählen

cat /lib/systemd/system/NetworkManager-wait-online.service
[Unit]
Description=Network Manager Wait Online
Documentation=man:nm-online(1)
Requisite=NetworkManager.service
After=NetworkManager.service
Before=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30
RemainAfterExit=yes

[Install]
WantedBy=network-online.target

Also, zumindest bis hier her hat sich an der Problematik nichts geändert. Zu Beginn kann ich hervorragend auf die Freigaben zugreifen, und dann kommt ein Zeitpunkt an dem z. B. der Dolphin oder der PCManFM-Qt einfriert, wenn ich in eine Freigabe möchte. Wenn ich dann sofort Gigolo starte und damit eine Freigabe einhänge und über diesen Weg den Dolphin öffne, kann ich zugreifen, obwohl der andere Dolphin noch hängt.
Die Mount-Units folgen diesem Prinzip:

Code: Alles auswählen

[Unit]
Description=Mount Network-Drives

Requires=network-online.target
After=NetworkManager-wait-online.service
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=strenggeheim,rw,nosuid,nodev,noexec,async
Options=username=jue,password=strengeheim,defaults,file_mode=0777,dir_mode=0777
Type=cifs

[Install]
WantedBy=multi-user.target

Fehlt da noch was?

[scientific]

Hi Jue

Speichere die beiden Units ftp-keepalive@.timer und ftp-keepalive@.service nach /etc/systemd/system/ und aktiviere sie so, wie am Ende meines Zitates angeführt für die Mountpoints.
Also nur den Timer pro Mountpoint!!!

Code: Alles auswählen

(0 ✓) root@aldebaran[/@debian-testing] (00:01) /etc/systemd/system: # cat ftp-keepalive@.timer 
[Unit]
PartOf= %i.mount
After= %i.mount
Before=umount.target
Conflicts=umount.target sleept.target suspend.target

[Timer]
OnActiveSec=10
OnUnitActiveSec=90

[Install]
WantedBy=%i.mount

Code: Alles auswählen

(0 ✓) root@aldebaran[/@debian-testing] (00:01) /etc/systemd/system: # cat ftp-keepalive@.service 
[Unit]
#Description=Keepalive FTP-Connection on %f

[Service]
#ExecStart=/bin/sh -c "/bin/ls %f > /dev/null"
ExecStart=/bin/sh -c "/usr/bin/stat %f > /dev/null"

Du kannst für jeden Mountpunkt (unabhängig ob über fstab oder explizite systemd-unit gehandhabt) extra dieses keep-alive-Timer aktivieren, indem du den Timer (nicht das Service!!!) enablest:

Code: Alles auswählen

systemctl enable ftp-keepalive@home-username-mount-point.timer

Damit wird dem Server angezeigt, dass das Verzeichnis eingehängt ist, auch wenn grad kein Datenverkehr stattfindet.

lg scientific

[jue]

DANKE! Jetzt muss ich testen, ob es funktioniert ... bis jetzt ist alles o.k., aber es dauert ja erfahrungsgemäss immer einige Zeit ...

Update@scientific: das war genial, ich sehe das Problem als gelöst an. Ich glaube es kaum ...

Herzlichen Dank für die absolut zähe und unnachgiebige Unterstützung an alle.

[TomL]

ich sehe das Problem als gelöst an.

Sorry... aber ich riskiere jetzt einfach mal, mich unbeliebt zu machen.... denn ich habe die Vermutung, dass das Problem überhaupt nicht gelöst ist, sondern nach wie vor besteht und nur mit einem Workaround umschifft wurde. Ich habe natürlich nicht den Vorsatz, mich unbeliebt zu machen, mich interessieren tatsächlich nur die technischen Aspekte. Und vor dem Hintergrund wäre das für mich bei erster Betrachtung allerdings keine optimale Lösung. Aber ich gestehe auch, dass ich für Timer-Units bisher keinen Bedarf hatte und diese Kombination hier ganz neu für mich war. Ich habe das natürlich gleich als wertvolle Idee erkannt und dieses Beispiel sicher in meiner Bibliothek "gebunkert". Aber...

... wenn ich das so bei mir umsetzen würde, hätte das für mich gleich mehrere negative Konsequenzen. Zum Beispiel, dass ich an meinem Server für 3 Platten den SpinDown nach einer bestimmten Zeit "unused" verhindern würde und weiterhin das Energiemanagement des Servers selber untergraben würde. Meine 3 Platten verschlafen garantiert im Jahresmittel 22 Stunden am Tag ... und das ganz unzweifelhaft zu meinem Vorteil sehr stromsparend. Bei der Keep-Alive-Lösung besteht aber genau der gegenteillige Effekt, und zwar durchlaufender Stromververbrauch während des ganzen Jahres. Wenn ich mich an meinen damaligen Windows-Server erinnere, hatte der in Ruhephasen einen Stromverbrauch von etwa 90 Watt. Mit CPU-Last und Lüfter und alle Schnittstellen "wach" gings rauf auf 110-120 Watt , unter Volllast manchmal bis zu 170 Watt. Ich vermute, dass diese stromsparende Ruhephase mit dem Keep-Alive komplett verhindert wird. Die erste-beste im Web gefundene interne Seagate 2TB-Desktop-HDD hat laut Datenblatt eine Leistungsaufnahme von fast 6 Watt. Ich rechne der Bequemlichkeit einfach mal nur mit 5 Watt. Das sind trotzdem über 40 KW/h im Jahr pro Platte, also deutlich über 120 KW/h jährlich bei meinen 3 Platten... und das bei steigenden Strompreisen. Optimal geht imho 'anders'.

Darüber hinaus befürchte ich, dass das auch einen erheblich negativen Einfluss auf die Lebenszeit einer normaler Desktop-Festplatte hat, weil deren einfaches Consumer-Getriebe nun faktisch 24/7 am Rennen ist, siehe Pkt.8.

Aber da ich eben kein Techniker bin und ich bei solchen Sachen auch immer falsch liegen kann, vielleicht kann mir jemand meinen Irrtum aufzeigen.....

[jue]

ich sehe das Problem als gelöst an.

Sorry... aber ich riskiere jetzt einfach mal, mich unbeliebt zu machen.... .

Keine Sorge, das sind wichtige Einwände. Ich hänge mit meinem Debian-Rechner an einem Windows-Server, an dem viele Windows-Rechner dran hängen. Während der Arbeitszeit kommt dieser Server nicht zur Ruhe. Und zum Feierabend schalte ich meinen Rechner - wie die anderen auch - aus, dann hat der Server Ruhe. Ich werde es alles beobachten und gegebenenfalls berichten. Aber sicher, mich würde es auch interessieren, was da ein Fachmann dazu sagt. Was mich persönlich stört ist, dass ich an meine Grenzen komme meinen eigenen Rechner einzurichten ...

[scientific]

Und aus dem Grunde, damit so ein Mount nicht dauernd aktiv ist, bevorzuge ich auch automounts mit auto-unmount nach einer Idle-Zeit.

Wenn du, jue, noch die fstab um folgende Option ergänzt:

Code: Alles auswählen

x-systemd.idle-timeout=30

oder eine automount-unit manuell mit folgendem Inhalt erstellst:

Code: Alles auswählen

cat /etc/systemd/system/home-jue-Servername-Freigabe.automount
[Unit]
Before=remote-fs.target
BindsTo=network-online.target
After=network-online.target

[Automount]
Where=/home/jue/Servername/Freigabe
TimeoutIdleSec=30

[Install]
WantedBy=network-online.target

Und dann die automount-Unit aktivierst mit

Code: Alles auswählen

systemctl enable home-jue-Servername-Freigabe.automount

Dann wird der Automount beim Herstellen der Netzwerkverbindung aktiviert. Sobald du auf den Mountpunkt zugreifst, wird gemountet.
Wichtig ist, dass die Idle-Zeit in der Automount-Unit kleiner ist als das Interval im keepalive-Timer.
Warum?
Wenn du von "außerhalb" ein z.B. ls auf den Mountpunkt loslässt, wird gemountet, und nach 30 Sekunden unmountet der Mountpunkt wieder.
Wenn du in der Shell oder im Dateiexplorer in ein Verzeichnis im Mountpunkt wechselst und dort drin stehst, sonst aber keinerlei Aktivitäten veranstaltest, würde dir die Verbindung "unterm Arsch" wegsterben. Damit das nicht passiert feuert der Keepalive-Timer alle 90 Sekunden ein stat ab und hält die Verbindung aufrecht.
Wechselst du wieder in ein Verzeichnis außerhalb des Mountpunktes, kommt wieder die Idle-Zeit zum tragen, die den Mountpunkt unmountet, bevor der Keepalive-Timer ein stat abfeuern kann.

Damit der Mountpunkt ausgehängt wird, wenn network-online.target gestoppt wird, wäre ein

Code: Alles auswählen

BindsTo=home-jue-Servername-Freigabe.automount

in die [Unit]-Section der Mount-Unit von Vorteil.

Das hat auch den Vorteil, dass der Automount nur bei aktiver Netzwerkverbindung "scharf" ist. Ist die Netzwerkverbindung nicht aktiv (hier muss noch eine weitere Ergänzung in den Networkmanager-dispatcher!!!!) blockiert ein ls oder gar nur eine bash-completion auf den Mountpoint das system NICHT, weil der Automount nicht aktiv ist.

Ich möchte nur anmerken, dass ich das alles schon früher in diesem Thread auch mal gepostet habe.

lg scientific

[scientific]

Was mich persönlich stört ist, dass ich an meine Grenzen komme meinen eigenen Rechner einzurichten ...

Nur wer an seine Grenzen stößt, kann diese erweitern.

Als ich mich das erste Mal mit systemd beschäftigt habe, hab ich überhaupt nicht verstanden, warum ich ein systemctl enable und ein systemd start benötige, wo doch das Erstellen eines Symlinks auch reichen würde... Und überhaupt, warum ist systemd so ein Schas...

Dann hab ich das Geranze über systemd, von dem ich so viel damals las, über Bord geworfen und mich mit dem Teil beschäftigt... Und bin weit über meine Grenzen hinausgewachsen und hab festgestellt, das Ding ist wirklich genial!!

Alles Gute!

Wenn du noch Hilfe benötigst, steh ich gerne zur Verfügung

lg scientific