[gelöst] Verzeichnis von Windows-Server einbinden

[TomL]

Ich habe ja die Freigaben wieder in der fstab aktiviert, die Dateien /etc/systemd/system/home-jue-servername-ordner.mount wieder gelöscht und bis jetzt hat alles funktioniert,

Dir muss nur klar sein, dass die fstab derzeit für Deine Netzwerk-Mounts ein reines Glücksspiel sind.... es kann funktionieren, klar, und wenn es das tut, dann musst Du das aber als glücklichen Zufall nehmen, ohne jegliche Garantie, dass das so bleibt oder das diese Lösung bei einer neuen Debian-Installation auch noch funktioniert. Die fstab ohne jegliche weitere steuernde Einflussnahme kann das eigentlich nicht. Und wenn Du Pech hast, läuft es jetzt ein paar Tage und nach dem nächsten upgrade, wenn Du schon gar nicht mehr daran denkst, fliegt es Dir wieder um Dir Ohren.

Such mal auf dieser Seite weiter unten nach "local-fs.target". Du wirst feststellen, dass systemd über den Autogenerator für jeden Eintrag in der fstab eine virtuelle Mount-Unit erzeugt. Das heisst, nicht die fstab verbindet, sondern in jedem Fall eine Mount-Unit. Wenn die Mount-Unit aus dem obigen Beispiel nicht funktioniert hat, dann liegt das an unterschiedlichen Options.
https://www.freedesktop.org/software/sy ... ecial.html

Du kannst Dir die aus der fstab generierten Mount-Options ansehen und ggf. die dann die neue Mount-Unit übernehmen. Es kann eigentlich nicht sein, dass das eine funktioniert, das andere aber nicht. Z.B.:

Code: Alles auswählen

cat /proc/mounts | grep Freigabe1 

So... warum überhaupt die eigene Mount-Unit? Weiter oben hast Du ja festgestellt, dass die fstab von local-fs.target behandelt wird. Schau Dir nun die folgende Ausgabe mit einem Picture-Viewer an... gthumb kann das, pinta und gimp auch, ich nutze gerne gpicview.

Code: Alles auswählen

systemd-analyze plot >~/bootplot.svg

Hier kannst Du genau den Boot-Prozess verfolgen. Und Du wirst feststellen, dass local-ts.target deutlich vor dem network.target angezogen wird. Das bedeutet, eine fstab mit Netzwerk-Mounts zu einem Zeitpunkt, wo das Netzwerk noch gar nicht gestartet oder vollständig verfügbar ist. Tja, wie gesagt, ein Glücksspiel.

Nachtrag:
Mir ist gerade noch mal aufgefallen, dass es sich ja um einen Windowsserver handelt...irgendwie hab ich Windows überhaupt nicht mehr im Blick. Möglicherweise braucht es ja da doch den filemode und dirmode in der Moutunit. Ich würde einfach die Optionen aus der fstab mal 1:1 übernmehmen und sehen,obs damit geht. Von Windows bin ich mittlerweile so weit weg, dass ich nicht mehr weiss, wie das da läuft.

[scientific]

remote-fs.target gibts auch noch.
Entferne aus der Mountunit das local-fs.target und setze

Code: Alles auswählen

 
After=remote-fs.target network-online.target 

Aber setzt der Generator das nicht sowieso, wenn man "netdev" in den Mountoptionen in der fstab hat? Hab das so in Erinnerung.

Lg scientific

[TomL]

remote-fs.target gibts auch noch.

Ja, wenn Du sicher bestätigen kannst, dass der Generator tatsächlich unterscheidet und bei CIFS-Mounts dort ein "Wants" dranhängt. Ich weiss das nicht. In der Man-Page gibts dazu auch keinen Hinweis auf die fstab. Und ich wüsste auch im Moment nicht, wie ich mir "$remote_fs" als Referenz im LSB-Header eines Scripts dafür nutzbar machen könnte, wo ich gar keine solcher Scripts mehr verwende.

Aber setzt der Generator das nicht sowieso, wenn man "netdev" in den Mountoptionen in der fstab hat?

Schau in der Man-Page nach, mount.cifs kennt den Parameter _netdev nicht. Schau im Sourcecode mount.cifs.c nach, dann wirst Du festellen, dass der Returncode bei "_netdev" ein OPT_IGNORE ist.

[scientific]

Also ich hab jetzt mal auf Stretch, heute full-upgrade gemacht, folgendes in die /etc/fstab eingetragen:

Code: Alles auswählen

//aldebaran/Public /home/scientific/smbtest cifs username=scientific,password=strenggeheim 0 0

aldebaran ist der Hostname meines Laptops. Ich hab einen Sambaserver eingerichtet und damit ein Verzeichnis freigegeben. Ich habe scientific mit smbpasswd ein Passwort für Samba verpasst und ich kann manuell diese Freigabe mounten.

Code: Alles auswählen

systemctl daemon-reload

erzeugt dann direkt folgende Mount-Unit:

Code: Alles auswählen

root@aldebaran # systemctl cat home-jakob-smbtest.mount 
# /run/systemd/generator/home-scientific-smbtest.mount
# Automatically generated by systemd-fstab-generator

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

[Mount]
What=//aldebaran/Public
Where=/home/scientific/smbtest
Type=cifs
Options=username=scientific,password=strenggeheim

Da kommt kein "local-fs.target" vor. Die Mountunit des Generators ist weit entfernt von irgendwie geschätzt und schaut sehr vernünftig aus. Verwendest du noch jessie, TomL?

systemctl show home-scientific-smbtest.mount gibt für Before und After folgendes bei obigem Eintrag in die fstab (ohne _netdev!!!)

Code: Alles auswählen

Before=umount.target remote-fs.target
After=remote-fs-pre.target network-online.target home.mount -.mount network.target system.slice

Dieser Befehl zeigt alle Abhängigkeiten - auch die Implizit hinzugefügten - einer Unit. Und offenbar fügt der Generator beim Filesystemtyp "cifs" die korrekten Abhängigkeiten zu den network-Targetes und auch zu remote-fs.target hinzu.

Aber setzt der Generator das nicht sowieso, wenn man "netdev" in den Mountoptionen in der fstab hat?

Schau in der Man-Page nach, mount.cifs kennt den Parameter _netdev nicht. Schau im Sourcecode mount.cifs.c nach, dann wirst Du festellen, dass der Returncode bei "_netdev" ein OPT_IGNORE ist.

Es geht ja um den Generator... der muss die korrekten Abhängigkeiten einfügen. Ich hab nachmittags nur per Handy und aus der Erinnerung posten können...
Wenn du die Optionen so durchsiehst, wird wohl kein einziges Mountprogramm eine Option "x-systemd.automount" kennen... und dennoch kann man diese Option in die fstab einfügen, da der Parser für den Generator für systemd dann für den Mountpoint auch noch eine Automount-Unit erzeugt.
Und wie mein Beispiel zeigt, reagiert der Parser offenbar auf den Filesystemtyp entsprechend, dass er unterschiedliche After= und Before= Abhängigkeiten setzt. Je nachdem was für dieses Filesystem korrekt ist.


lg scientific

[TomL]

Wenn du die Optionen so durchsiehst, wird wohl kein einziges Mountprogramm eine Option "x-systemd.automount" kennen... und dennoch kann man diese Option in die fstab einfügen, da der Parser für den Generator für systemd dann für den Mountpoint auch noch eine Automount-Unit erzeugt.

Was hat denn ein zusätzlich eingefügter Parameter für den Autogenerator mit den Parametern zu tun, die letztendlich mount.cifs.c behandelt? Gar nix, der dient nur dazu Abhängigkeiten in den Units zu definiereren., die wiederum nur für systemd interessant sind.

Und wie mein Beispiel zeigt, reagiert der Parser offenbar auf den Filesystemtyp entsprechend, dass er unterschiedliche After= und Before= Abhängigkeiten setzt. Je nachdem was für dieses Filesystem korrekt ist.

Ich habe das bei mir auch mal genau so nachgespielt... alles genau so eingestellt, nur funktioniert es leider nicht. Es scheitert bei mir letztendlich daran, dass die Mount-Unit nicht auf den DHCP-Client wartet. Das heisst, dhclient und die Mount-Unit werden etwa zeitgleich gestartet, nachdem das Netzwerk gestartet wurde. Nur ist dann die Netzwerk-Verbindung noch nicht etabliert, es wurde noch keine IP vergeben und die Unit failed. Wie sich das jetzt auch noch unter Einfluss des NM verhält oder wenn das Netzwerk mit systemd-networkd oder vielleicht sogar noch via /etc/init.d/networking gestartet wird, weiss ich nicht. Ich bewerte den ganzen Kram weniger als geschätzt und kaum zufällig funktionierend. Nicht umsonst ist das Netz voll von solchen Problemen mit Netzwerk-Mounts. Und wenn dann auch noch WLAN beteiligt ist, wirds ein völliges Glückspiel

Aber das ist jetzt alles sinnloses Geschwafel um des Schwafelns willen und ich habe da kein Bock mehr drauf. Du sagtest dieser Tage, bei mir wäre alles anders. Nein, ist es nicht, ich denke, wir verfolgen nur völlig entgegengesetzte Strategien. Für mich gilt in allen Belangen, so schnörkellos, un­prä­ten­ti­ös und unkompliziert wie möglich.... weil das das einzige ist, was ich halbwegs verstehe und im Griff habe. Ich will keine komplizierten unterschiedlichen Lösungen, die ich von System zu System anpassen muss, nur weil die Bedingungen das Netzwerk zu etablieren unterschiedlich sind. Und das hier jetzt weiter zu vertiefen, ist nur krampfhaftes Suchen nach Lösungen, für die es Anfangs kein Problem gab. Dafür ist mir die Zeit zu schade. Wenn es jetzt hier mit der fstab geht, gut. Wenn es mit der mount-unit geht, auch gut. Ansonsten...

...viele Köche verderben den Brei.... ich schau deshalb mal zu, wie das eigentliche Problem mit Deiner Hilfe gelöst wird.

[jue]

Ich kann eurer Diskussion im Moment nicht mehr folgen, werde mir aber nochmal alles in Ruhe durchlesen, mich orientieren und schauen, was ich machen kann. Früher hatte ich nie Probleme Windows-Freigaben über die fstab zu mounten. Klar kam mal die Umstellung auf cifs, nach einer Minute Googeln habe ich aber gefunden, wie es gemacht wird. Jetzt wird das scheinbar komplizierter. Als Anwender will ich natürlich zumindest meinen eigenen Rechner einrichten können und ich werde mich auch mit systemd und den Mount-Units beschäftigen. Ich werde an dieser Stelle berichten. Danke für die bisherige Unterstützung, für weitere Tipps bin ich natürlich dankbar.

[jue]

... Du kannst Dir die aus der fstab generierten Mount-Options ansehen und ggf. die dann die neue Mount-Unit übernehmen.

Die generierte Mount-Option sieht anders aus:

Code: Alles auswählen

//192.168.10.xxx/Freigabe1$ /home/jue/Servername/Freigabe cifs rw,relatime,vers=1.0,cache=strict,username=jue,domain=xxx-yy,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.xxx,file_mode=0777,dir_mode=0777,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1 0 0

Die, die ich geschrieben habe sah so aus:

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

Mir fällt auf, dass die Zeile, in der file_mode=0777,dir_mode=0777 drin ist, auskommentiert ist. Ebenso ist domain=xxx-yy nirgends enthalten.
Ich gebe zu, ich habe Probleme die generierte Mount-Option auf meine selbst geschriebene zu übertragen ...

[TomL]

Ich kann eurer Diskussion im Moment nicht mehr folgen,

Ja, das ist auch ok, weil das eine völlig unnötige Dikskussion war, wirklich nur sinnlose Zeitverschwendung. Fakt ist, und warum ich immer sage, dass das ein Schätzergebnis und Glückspiel ist, dass es im "Mischbetrieb" keine definitive Aussage darüber gibt, was "Das Netzwerk ist gestartet" überhaupt bedeutet.

"Mischbetrieb" ist wieder so ein Begriff in ähnlicher Qualität wie "Geschätzt" oder "Glücksspiel". Debian befindet sich seit Jessie in eine Übergangsphase, eben dieser Mischbetrieb, in der es sich immer noch nicht von sysvinit gelöst hat. Das heisst, vom Installer wird immer noch das alte Init-Script "networking" installiert und erst mal gestartet. Unter Jessie handelt meiner Meinung nach der Networkmanager immer noch nach sysv-Regeln und kappt ohne Rückfrage nach eigenem Ermessen Verbindungen. Es gibt immer noch keinen vorgegebenen Netzwerkstart, außer vielleicht das überholte noch aus wheezy stammden "networking". Man kann das Netz aber alternativ auch über die Tools aus iproute2 starten (das tue ich), oder über das erwähnte networking, oder über einen der Networkmanager, oder über systemd-networkd. Wegen dieser unterschiedlichen Möglichkeiten gibt es immer noch keine ultimative Feststellung "Verbindung hergestellt". Das network-online.target, welches ja einen Zustand über das Netzwerk aussagen soll, kann also je nach Umgebung alles mögliche aussagen... von networkmanager ist gestartet, über Schnittstellen sind geöffnegt/initialisiert, über dhcp-Client fordert IP an, bis hin zu IP ist vergeben. Es gib keine ultimative Festlegung, was network-online.target bedeutet. Hast Du auf dem einen Rechner eine schnelle Kabelverbindung steht das Netz in 3 Sekunden. Nimmst Du die gleiche Lösung und transportierst die auf einen WLAN-PI wird es in 99 von 100 fehlschlagen, weil der PI bis hin zu 20 Sekunden für die Verbindung braucht. Da sind dann alle abhängigen services "failed", eben auch die Netzwerk-Mounts. Das gleiche passiert beim Laptop, je nachdem, wo Du im Garten sitzt. Beschattet Deine Sitzung vom WLAN-Router gerade ein in der Wand befindlicher Stahlträger, verfünfacht sich die Connect-Zeit, da platzen beim Boot alle Mounts, die nach diesen vagen Schätzmethoden irgendwo in den Bootprozess eingereiht wurden.

Wie gesagt, unter solchen Bedingungen ist der erfolgreich Betrieb immer auch das Ergebnis eines glücklichen Zufalls. Kabel ist einfach, WLAN hat haufenweise störende Einflussbedingungen. Eine Lösung könnte es sein, das Netzwerk generell über systemd-networkd zu starten und dann die Unit network-wait-online.serve zu nutzen. Die sollte eigentlich darauf warten, bis das Netzwerk etabliert erfolgreich etabliert ist. Da dies aber eine aktive Unit ist, die den Start faktisch aktiv delay'ed, halte ich nicht so viel davon... muss muss das ja in jede Mount-Unit eintragen. Oder man erstellt sich ein dazu passendes eigenes Target, aber dazu bedarf es dann schon fortgeschrittener systemd-Kenntnisse. Ein fstab-Mount wird durch den Generator gemäß vorgegebener Standards generisch erzeugt, mal passt es, mal nicht. Auf eine eigene Mount-Unit kann man präzisierend deutlich mehr Einfluss nehmen.

Mein persönlich favorisierte Lösung ist, der Art des Netzwerkstarts überhaupt keine Bedeutung mehr zu schenken. Mir ist es egal, wie und von wem das Netzwerk gestartet wird. Ich will auch keinen Delay der Bootphase, sondern einfach nur, dass die Mounts dann erfolgen, wenn das Netzwerk verbunden ist... also eine IP vergeben wurde. Dieser Lösung ist es egal, ob das 3 oder 60 Sekunden dauert, solange es nur innerhalb des Timeouts von 90 Sekunden erfolgt. Und wer das Netz gestartet hat, ist mir bei dieser Lösung auch egal. Somit kann ich das auf alle Systeme ohne Anpassungsaufwand übernehmen... und es funktioniert immer und auf Anhieb.

j.m.2.c.

[TRex]

Ich hoffe, nicht übermäßig zur "unnötigen Diskussion" beizutragen, aber hier noch folgendes:

Mir ist es egal, wie und von wem das Netzwerk gestartet wird.

"das Netzwerk" bringt dir eh nix. Welches denn? Ich würde es anders angehen (und ich weiß nicht, ob mir systemd dabei helfen kann; die meisten anderen tun es nicht):

1. ein "target", das mir Internet verspricht, egal über welche Leitung. Was passiert, wenn das wechselt (wlan/mobil), weiß ich auch nicht.
2. für LAN-Mounts: prüfe, ob das Ziel erreichbar ist. Wenn nicht, dann mounte es nicht. Du hast nämlich nichts davon, bei deinem Kumpel zu Besuch zu sein und dein _netdev meldet, dass das NFS jetzt zu mounten sei.

Aber das ist nur Wunschdenken, wie man das Handling von Netzwerkmounts verbessern könnte... Status quo ist, dass es eher unbefriedigend ist. Ein Shellscript hinter einer unitfile könnte helfen, muss aber nicht.

[TomL]

Code: Alles auswählen

//192.168.10.xxx/Freigabe1$ /home/jue/Servername/Freigabe cifs rw,relatime,vers=1.0,cache=strict,username=jue,domain=xxx-yy,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.xxx,file_mode=0777,dir_mode=0777,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1 0 0

Ich gebe zu, ich habe Probleme die generierte Mount-Option auf meine selbst geschriebene zu übertragen ...

Eigentlich ist das gar nicht so kompliziert. Ich würde einfach genau die gleichen Optionen aus der fstab in die Unit eintragen und testen, ob es damit läuft. ggf. wie oben mit dem cat-Befehl vergleichen, ob was anderes rausgekommen ist

Diese Zeile stand ja schon drin, mit einem Comment-Tag versehen. Also einfach den '#' auf die andere Zeile setzen und fertig.

Code: Alles auswählen

Options=username=jue,password=geheim,defaults,file_mode=0777,dir_mode=0777

Wenn es nun mit den Schreibrechten nach Start der Unit klappt, ist das Problem erst mal gelöst.

Code: Alles auswählen

systemctl start $unitname$.service

Ob es dann noch zu weiteren Problem kommt, e ben die zuvor erwähntenchronologischen, muss man sehen und die dann lösen. Die Basis bleibt aber die Mount-Unit.

BTW, es gibt auch noch eine andere ablosut sicher funktionierende Lösung, die auch leicht zu handhaben ist und in jeder Hinsicht transportierbar ist. Versuchs erst mal, ob es so klappt.... das wäre ja dann ok. Und wenn nicht, gibts alternativen.

[TomL]

Ich hoffe, nicht übermäßig zur "unnötigen Diskussion" beizutragen, aber hier noch folgendes

Nein, absolut nicht... weil genau das die perfekte Lösung ist.

Ich habe das bei mir hiermit gelöst, wo ich genau auf das "Ziel" warte... das funktioniert tatsächlich immer.
viewtopic.php?f=34&t=164467&p=1124762#p1124749

In meinen Mounts beziehe ich mich einfach auf diese Unit und alle warten schön darauf, bis die Verbindung besteht.

[jue]

Also einfach den '#' auf die andere Zeile setzen und fertig.

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

Beim Verschieben von Dokumenten vom eigenen Rechner auf den Server gibt es aber immer noch Probleme. Im Dolphin kommt die Meldung "Zugriff verweigert". Wenn ich abbreche, stürzt er ab. Die Dokumente werden aber scheinbar trotzdem verschoben Das ist aber vielleicht ein Dolphin-Problem, mit spacefm, pcmanfmqt und pcmanfm funktioniert alles. Ich werde weiter testen und berichten.

Update: es ist wie zuvor. Wenn ich beginne mit dem Rechner zu arbeiten, kann ich auf alle Freigaben zugreifen. Aber nach einer gewissen Zeit geht das nicht mehr. Wenn ich mit einem der oben genannten Dateimanager auf eine Freigabe zugreifen möchte, hängt der Dateimanager und nichts geht mehr. Wenn ich die Freigabe selbst in der Zeit, in der alles hängt mit gigolo mounte, kann ich zugreifen. gigolo mountet die Freigabe aber natürlich anders über gvfs woanders hin. Ich würde ja einfach pragmatisch gigolo nehmen, aber da habe ich wieder das Problem, dass ich mit Libreoffice nicht speichern kann.

[scientific]

Schön, dass Beiträge, die dir zu kompliziert sind, völlig unnötige Diskussionen sind... @TomL

Ich werds mir merken.

[scientific]

Das Target, welches funktionierendes Netzwerk verspricht, könnte NetworkManager-wait-online.target sein.

[TomL]

Schön, dass Beiträge, die dir zu kompliziert sind, völlig unnötige Diskussionen sind....

Nein, die sind mir nicht zu kompliziert. Mir gehts nur auf den Senkel, dass Du dich nicht mit dem Eingangsproblem des TE auseinandersetzt, sondern die Beiträge, die zu helfen beabsichtigt sind, mit einem ätzenden "Herr Lehrer Herr Lehrer, ich weiss es aber besser" zu zerlegen versuchst. Darüber hinaus verlässt Du ständig das Thema und machst völlig unnötig Nebenkriegsschauplätze auf, die gar nix mehr mit dem Eingangsproblem zu tun haben.

Ich bin kein gegen Entgelt arbeitender zertifizierter Linuxfachmann, sondern Rentner und Laie und habe Zeit und mir macht es Spass, nach bestem Wissen und Gewissen mit einfachen Worten und Erklärungen zu helfen - basierend auf meinen Erfahrungen und wie ich Debian bisher verstanden habe. Und das ganz ohne Anspruch auf Vollständigkeit oder ultimative Richtigkeit. Ich schreibe nur, was ich erfolgreich umgesetzt habe. Auf diese dummen Kindergartenwettbewerbe, wer 3 Gramm mehr Recht bei einem unwichtigen Detail hat, habe ich schlichtweg keinen Bock, das ist mir einfach zu albern und die Zeit dafür zu schade. Wenn Dir meine Formulierungen oder Ratschläge nicht gefallen, dann mach einfach bessere, ohne Bezug auf meine Texte. Wenn Deine Ideen besser sind, werde ich das ganz sicher auch für mich übernehmen.

ps
In gewohnter Manier kannst Du Dich nun wieder darüber echauffieren, dass man "Recht haben" nicht in Gramm bemisst

[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