[gelöst] Verzeichnis von Windows-Server einbinden

[jue]

Das kann ich mir grad nicht vorstellen.

Die Freigaben sehen in meiner fstab so aus:

Code: Alles auswählen

//192.168.10.xxx/Freigabe1$   /home/jue/Servername/Freigabe1 cifs  defaults,username=jue,password=geheim,file_mode=0777,dir_mode=0777   0   0
//192.168.10.xxx/Freigabe2r$   /home/jue/Servername/Freigabe2 cifs  defaults,username=jue,password=geheim,file_mode=0777,dir_mode=0777   0   0
//192.168.10.xxx/Freigabe3$   /home/jue/Servername/Freigabe3 cifs  defaults,username=jue,password=geheim,file_mode=0777,dir_mode=0777   0   0
//192.168.10.xxx/Freigabe4$   /home/jue/Servername/Freigabe4 cifs  defaults,username=jue,password=geheim,file_mode=0777,dir_mode=0777   0   0
//192.168.10.xxx/Freigabe5$   /home/jue/Servername/Freigabe5 cifs  defaults,username=jue,password=geheim,file_mode=0777,dir_mode=0777   0   0

Ja, ich könnte "file_mode=0777,dir_mode=0777 0 0" weglassen, es stört hier ja aber nicht.
Ich weiss nix, werde aber mal weiter testen ...

[jue]

.. 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.

Einfach apt-get remove --purge network-manager?
connman habe ich auch noch gefunden. Sind da Konflikte bekannt?

[scientific]

Da wär ich vorsichtig. Wenn du dich mit den Alternativen nicht auskennst, stehst du am Ende gar ohne Netzwerk da und kannst nicht einmal mehr etwas installieren...

Lg scientific

[TomL]

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.

Ja, gibt es... zwar keine Weiterentwicklung, die den NM besser funktionieren lässt, sondern eine, die diesen "Usercase" ganz ohne NM abdeckt.

Einfach apt-get remove --purge network-manager?

Nee, nicht ... .... solange nicht, wie du nicht weisst, wie du das Netz alternativ manuell ans Rennen bringst.

Wenn es ein an festem Ort stehender PC mit Ethernet-Kabel ist, ist es einfach. Wenn es sich um eine mobilen Laptop handelt, der sich mit wechselnden Netzen verbinden soll, ist da schon eine programmliche Hilfe sinnvoll.... aber das muss eben kein klassicher Networkmanager, das geht auch einfach ohne diese Krücken. Aber es sollte schon klar sein, was am Ende dabei rauskommen soll.

Also, ohne zusätzliche Infos übere das Gerät, die Art der Netzanbindung und vor allem das Desktop-Environment würde ich den purge nicht durchführen. Statt sofort zu "purgen" kann man den Prozess auch einfach deaktivieren oder maskieren.... je nachdem, was besser ist.

[jue]

Nee, nicht ... ....

Keine Sorge, zuerstmal bleibt der nm drauf.
Ich habe jetzt noch eine komische Erfahrung gemacht, die ich aber nicht recht einschätzen kann: 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, so dass ich bis zum Feierabend auf alle Freigaben problemlos zugreifen konnte, was zuvor so eine lange Zeit nicht möglich war, weil immer etwas blockiert hat, der Dolphin hängen geblieben ist, wenn ich auf etwas zugreifen wollte usw. Ich weiß natürlich nicht, ob das morgen so weiter geht, habe aber Hoffnung. Woran das liegen kann, kann ich mir auch nicht vorstellen, aber ich habe ja das alles zuerst getan, was Tom empfohlen hat (Versuchs mal auf eine ganz andere Weise... ), wieder rückgängig gemacht und ich habe auch D-Us gemacht. Irgend etwas ist jetzt anders. Der Rechner ist super herunter gefahren. Beim Booten sehe ich aber nicht mehr viel, der Recher ist jetzt raz-faz beim Anmelden bei SDDM. Na ja, ich traue der Sache noch nicht, bin auf Morgen gespannt ...

[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