< zurück >

Mountctl …. wozu das denn?

...*hmmm*.... fast eine gute Frage. Auf die ich allerdings keine bessere Antwort habe als "Weil es funktioniert!". Dabei ist mir natürlich bewusst, dass nicht alles was funktioniert auch wirklich sinnvoll und gut ist.  Die bessere Frage wäre vielleicht "Muss eine Lösung wirklich so kompliziert sein?" Auch auf die Frage habe ich wirklich keine gescheite Antwort. Fakt ist, das Mounten von Netzwerkplatten auf einem (mobilen?) Enduser-Desktop-PC ist meiner Meinung nach unter Linux bei bestimmten Anforderungen absolut unbefriedigend gelöst und von haufenweise unschönen oder sogar problematischen Nebeneffekten begleitet. Fakt ist, die fstab entstammt einer Zeit, zu der vermutlich noch niemand das willkürliche Ein- und Ausschalten eines (mobilen?) Desktop-PCs und das dynamische Mounten und Umounten von Netzwerkplatten im Sinne hatte, wozu auch noch die User selber berechtigt sein sollen. Die Stärken der fstab liegen also ganz sicher im statischen System, einschalten, mounten und dauerhaft laufen lassen. Dieser grundsätzliche Gedanke ist aber völlig inkompatibel zu einem Laptop, der sich mal hier, mal dort mit irgendwelchen Netzen verbindet, und mal die Netzwerkplatten mountet und beim nächsten Einschalten eben nicht. Also scheint die Sachlage doch etwas komplizierter zu sein, als anfangs angenommen.

Und weil das meiner Meinung nach so eine komplizierte Angelegenheit ist, die die fstab tatsächlich nicht akzeptabel handhaben kann, ist meine Lösung auch dementsprechend kompliziert ausgefallen. Ich habe zuvor vieles getestet, um vielleicht mit dem einen oder anderen Verfahren eine vernünftige Lösung einzustellen. Ich habe versuchsweise mit PAM-Mounts experimentiert, mit automounts, traditionell mit der fstab sowieso, mit systemd - irgendwie war nichts dabei, was meinen Anspruch an 'reproduzierbar und stabil' auch wirklich zufriedenstellend erfüllt hat. Irgendein ungelöstes Problem bestand immer. Um die Zusammenhänge und Probleme besser zu verstehen, sind jetzt jedoch ein paar weitergehende Erläuterungen und Betrachtungen notwendig.

Dabei hilft ein kurzer Blick auf ein Muster einer meiner frühen fstab's, die prinzipiell genau so und identisch auf all unseren Systemen eingerichtet werden sollte. Das ist übrigens eine unverzichtbare und alternativlose Prämisse: Ich will keinesfalls geräte-individuelles Customizing betreiben... der Aufwand wäre mir viel zu hoch. Eine Lösung muss für alle Systeme anwendbar sein, idealerweise durch einfaches Kopieren von einigen wenigen immer gleichen Dateien an immer die gleichen Zielorte. So sehen also Beispielhaft unsere Remote-Mounts aus, die -idealerweise, je nachdem, wer sich anmeldet- gemountet werden sollen:

# Admin-Shares

//172.1.1.2/Disk_1       /media/Disk_1       cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/Disk_2       /media/Disk_2       cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/SSD_1        /media/SSD_1        cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/Install      /media/Install      cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

# Public Shares

//172.1.1.2/Buch         /media/Buch         cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/Film         /media/Film         cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/CD           /media/CD           cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/Downloads    /media/Downloads    cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/DatenAlle    /media/DatenAlle    cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,noexec,nouser,async

# Private Shares

//172.1.1.2/homes/Daten  /home/thomas/SHome  cifs  credentials=/home/thomas/.smbcred,uid=thomas,gid=thomas,rw,auto,nosuid,nodev,nouser,async

//172.1.1.2/homes/Daten  /home/silvia/SHome  cifs  credentials=/home/silvia/.smbcred,uid=silvia,gid=silvia,rw,auto,nosuid,nodev,nouser,async

//172.1.1.2/homes/Daten  /home/manuel/SHome  cifs  credentials=/home/manuel/.smbcred,uid=manuel,gid=manuel,rw,auto,nosuid,nodev,nouser,async

//172.1.1.2/homes/Daten  /home/steffi/SHome  cifs  credentials=/home/steffi/.smbcred,uid=steffi,gid=steffi,rw,auto,nosuid,nodev,nouser,async

//172.1.1.2/homes/Daten  /home/bibi/SHome    cifs  credentials=/home/bibi/.smbcred,uid=bibi,gid=bibi,rw,auto,nosuid,nodev,nouser,async

//172.1.1.2/homes/Daten  /home/marco/SHome   cifs  credentials=/home/marco/.smbcred,uid=marco,gid=marco,rw,auto,nosuid,nodev,nouser,async

Die oben stehende fstab sieht völlig normal und unspektakulär aus - Admin-Shares, auf die nur ich zugreifen darf,  Public-Shares, die von allen verwendet werden und persönliche Verzeichnisse, auf die nur der User selber Zugriff hat. Die Besonderheit an dieser fstab ist der Umstand, dass sie einfach nicht funktioniert. Aber diese Besonderheit ist gleichzeitig nach meinen Erfahrungen auch Linux-Normalität. Wenn man eine Zeitlang regelmäßig diverse Linux-Foren besucht, erfährt man, dass das ein ständig wiederkehrendes Problem ist, an dem unzählige User scheitern. Und welche Probleme gibt es damit...?... einige! Um einmal die bei uns vorhandenen Probleme zu verstehen, muss man vorher noch einige Rahmenbedingungen unseres Netzwerkes und der Art und Weise unserer Hardware-Nutzung kennen:

Alle unsere Rechner sind so eingestellt, dass typische Anwender-Daten zentral auf dem Server gespeichert werden, Dateien wie Office-Dokumente, Mails, Kontakte und Termindaten, etc.  Alle PCs haben trotzdem für jeden User lokale Homedirs.

Es gibt bei uns Multiuser-PC/Laptops, an denen sich je nach Bedarf verschiedene Personen anmelden, die natürlich an jedem PC jeweils ihre eigenen Daten sehen wollen. Wer sich wann und wo anmeldet, ist willkürlich

Es gibt Laptops, die sich via WLAN anmelden und die von Fall zu Fall ebenfalls von verschiedenen Personen jeweils mit ihrem eigenen Account und ihren eigenen Daten genutzt werden wollen

Unsere Laptops melden sich zum Teil auch an wechselnden WLAN-Netzen an. Zum Beispiel meldet sich der Laptop meines Sohns Zuhause an, in der Uni und bei der Freundin. Ich wechsele den WLAN-Anbieter mit meinem Laptop auf Reise täglich. Das heißt, die fstab soll die Mounts durchführen, wenn wir uns zuhause verbinden, sie darf aber nicht blockieren, wenn wir uns in fremden Netzen anmelden

Aus diesem Umfeld und diesen speziellen Anforderungen resultieren in der Folge einige Probleme:

1.

Die fstab wird beim Systemstart abgearbeitet wird, also ein Zeitpunkt, an dem nicht bekannt ist, wer sich auf einem Multiuser-PC irgendwann anmelden wird und ob sich vielleicht sogar nacheinander verschiedene User anmelden. Also müssen immer alle Mounts auf allen Clients quasi vorauseilend mit einer umfassenden Berechtigung hergestellt werden, eine Berechtigung, die tatsächlich alle Fälle umfasst. Die Folge ist, auf dem Server ist nicht transparent ersichtlich, welcher User letztendlich die Mounts verwendet hat. User- oder Gruppenbezogene Samba-Berechtigungen werden damit quasi außer Kraft gesetzt.

2.

Weil beim Systemstart unbekannt ist, ob und wer sich anmeldet, müssen also immer (quasi vorauseilend) alle Mounts hergestellt werden, auch die, die für diese Anmeldung gar nicht gebraucht werden oder wenn spezielle Ressourcen an  'andere‘ User gebunden sind.

3.

Wenn die Laptops sich via WLAN verbinden, schlägt der Mount beim Systemstart immer fehl, weil die fstab vom System abgearbeitet wird, bevor das Netzwerk gestartet und verbunden ist und die gewünschte Ressource noch nicht erreichbar ist.

4.

Bei Einsatz eines Network-Managers und einer WLAN-Verbindung passiert es oft oder regelmäßig, dass der NMW beim Shutdown des Rechners die WLAN-Netzwerkverbindung trennt, bevor die Mounts getrennt sind. Daraus resultieren dann beim Runterfahren des Rechners diese 120-Sekunden-Stopjobs beim Versuch des Umounts, was ja jetzt gar nicht mehr möglich ist, und in Folge dessen die Blockierung des Shutdown-Prozesses

Kurz zusammengefasst bestehen also diese Probleme:

X

Die fstab unterscheidet nicht nach User und wartet nicht aufs Netzwerk

X

PAM-Mount unterscheidet zwar nach User, wartet aber auch nicht aufs Netzwerk

X

Systemd-Mounts können zwar auf eine Netzwerkverbindung warten, aber nicht erkennen, ob es das richtige Netzwerk mit Samba-Server ist, und sie unterscheiden ebenfalls keine User. Die Mounts erfolgen im Boot-Prozess, wo wiederum nicht bekannt ist, welcher User sich 'später' anmelden wird.

X

Warten bis das Netzwerk bereit ist, bedeutet nicht auf irgendein Netz zu warten, sondern auch festzustellen, ob der Samba-Server in diesem Netz überhaupt erreichbar ist

X

Automounts warten weder aufs Netzwerk, noch unterscheiden sie nach User… der User bekommt, was er öffnet (sofern er berechtigt ist, das Netzwerk verbunden ist und die Ressource verfügbar ist). User-Bezogene Samba-Berechtigungen sind nicht verfügbar

X

Es gibt so gut wie keine Unterstützung bzw. Abstimmung zwischen Mount und Netzwerkverbindung für On-the-fly-Mounts via OpenVPN, wenn unterwegs fremde Netze verbunden sind

Die oben aufgezählten Probleme habe ich heute mit einer fstab gelöst, die nun auf all unseren Systemen völlig identisch folgendermaßen aussieht:

# Admin-Shares

//172.1.1.2/Disk_1       /media/Disk_1      cifs   credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async

//172.1.1.2/Disk_2       /media/Disk_2      cifs   credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/SSD_1        /media/SSD_1       cifs   credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/Install      /media/Install     cifs   credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async    

# Public Shares

//172.1.1.2/Buch         /media/Buch        cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/Film         /media/Film        cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/CD           /media/CD          cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/Downloads    /media/Downloads   cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async    

//172.1.1.2/DatenAlle    /media/DatenAlle   cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async    

# Private Shares

//172.1.1.2/homes/Daten  /home/1000/SHome   cifs   credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,nouser,async

Warum funktioniert dieses Beispiel und das erste Beispiel oben nicht...?... die sehen doch fast gleich aus. Ganz einfach, diese fstab führt nicht mehr zu Fehlern, weil sie gar nicht erst versucht, die Laufwerke zu mounten. Durch die Mount-Option "noauto" beachtet die fstab diesen Eintrag im Boot-Vorgang schlichtweg nicht mehr. Damit ist das erste Problem gelöst, und zwar auf Fehler laufende Mount-Versuche durch das System, weil der Server 172.1.1.2 bei Anmeldung an fremden Netzen durch einen Laptop gar nicht verfügbar oder bei langsamen WLAN-Verbindung noch nicht verfügbar ist.

Nun muss das zweite Problem gelöst werden.... nicht nur die Mounts durchzuführen, sondern das auch noch userbezogen, und zwar so, dass die Laufwerke gemountet sind, wenn sich der User angemeldet hat. Das bedeutet, wenn sich beispielsweise der User "silvia" anmeldet, dann sollen NICHT die Admins-Shares gemountet werden, denn die gehören ja "thomas:thomas", sondern nur die Public-Shares, auf die Silvia vielleicht zugreifen möchte und natürlich auch ihr eigenes und persönliches Datenverzeichnis auf dem Server. Keinesfalls sollen gleichzeitig auch noch die anderen User-Verzeichnisse (siehe oben erstes Beispiel) gemountet werden.

Dieses Problem habe ich mit dem Script /usr/local/bin/mountctl gelöst, welches die fstab parsen und interpretieren soll. Nachdem sich der User im System angemeldet hat, ist dieser User natürlich bekannt und kann via Script ermittelt werden. Passt der angemeldete User zu den fstab-Einträgen (Beispiel: "uid=thomas,gid=thomas" ), soll die Ressource gemountet werden, sonst nicht. Alle Mounts, die sich auf die ID 1000 beziehen, werden mit den Credentials dieses Users gemountet. Das bedeutet bezogen auf die zuvor genannte Anmeldung,  die "1000" wird durch "silvia" ersetzt und damit greifen im vollen Umfang die auf dem Samba-Server für "silvia" gesetzten Rechte. Gerade das ist bemerkenswert, weil eben genau das im oberen ersten Beispiel nicht der Fall wäre. Bei der fstab aus dem oberen Beispiel müsste ich "silvia" auf jedem einzelnen PC die Rechte entziehen, wenn das aus irgendeinem Grund notwendig wäre. Mit der unteren fstab und dem Script mountctl tue ich das nur einmal auf dem Server. Das ist ein großer Vorteil. Weil außerdem 'angemeldeter User silvia' nicht zum Eintrag 'uid=thomas' passt, werden die Admin-shares nicht gemountet. Und schließlich, weil hier im Gegensatz zum ersten Beispiel auch nur ein User-Mount eingetragen ist, der dynamisch für jeden User individuell genutzt wird, ist auch das vorauseilende mounten aller vorhandenen user-eigenen Shares nicht mehr notwendig.

Das dritte zu lösende Problem ist nun die Verfügbarkeit und die Erreichbarkeit des Servers festzustellen. Nur festzustellen "Netzwerk ist verbunden" reicht nicht aus. Denn irgendein Netzwerk kann auch irgendwo im Ausland bei McCafe oder auf irgendeiner Bank in irgendeiner City mit offenem WLAN-Angebot verbunden sein... aber genau da gibt's unseren Homeserver eben nicht... zumindest nicht beim Systemstart.... vielleicht etwas später nach Start des OpenVPN-Services. Die Prüfung auf explizite Erreichbarkeit unseres Servers übernimmt das Script /usr/local/bin/serverctl.

Das letzte zu lösende Problem besteht darin, die beiden zuvor beschriebenen Prozesse genau dann auszuführen, wenn sich der User am System mit Username und Password angemeldet hat. Diese Aufgabe übernimmt wiederum ein Script, und zwar /usr/local/bin/sessionctl. Um das Script sessionctl genau passend zur Useranmeldung  zu starten, nutze ich eine Systemfunktion der PAM-Infrastruktur, welche die Useranmeldung als Ereignis erkennt und mir ermöglicht, jetzt das Script zu starten. Sessionctl startet daraufhin mountctl.service, welches zwingend abhängig von serverctl.service ist, wodurch in der Verarbeitungsreihenfolge über serverctl  geprüft wird, ob der Server überhaupt erreichbar ist. Ist der Server nicht erreichbar, wird erst gar nicht ein zum Scheitern verurteilter Mount-Versuch gestartet.

In dieser Job-Kette besteht noch ein besonderer Umstand. Das Script mountctl wird nicht direkt gestartet, was zwar durchaus möglich ist, aber was ich nicht empfehle. Es wird immer über die Service-Unit /etc/systemd/system/mountctl.service gestartet. Erst diese Service-Unit gewährleistet, dass z.B. beim Shutdown oder beim Trennen der Netzwerkverbindungen vorher die Remote-Laufwerke ordentlich umounted werden. Die mountctl-Service-Unit wird zudem auch von meinem kleinen Networkmanager selnic unterstützt, woraus in der Folge dann eine in sich logisch geschlossene Verarbeitung stattfindet, die zu keiner Zeit ein Blockieren des Systems zulässt. Weder beim Starten des Systems gibt es Probleme, wenn das Netz für die Mounts noch gar nicht bereit ist, noch beim Shutdown, wenn sicher gestellt ist, dass die Remote-Mounts geschlossen sind, bevor die Netzwerkverbindung getrennt wird. Das gleich passiert auch auf sichere Weise, wenn unterwegs via OpenVPN das Heimnetzwerk verbunden wurde und die Mounts manuell über die Service-Unit oder über selnic geöffnet sind. Sobald entweder das Netzwerk oder die OpenVPN-Verbindung getrennt wird, werden vorher ggf. vorhandene Mounts zum Homeserver ordentlich geschlossen.

Die Prozesse für Remote-Mounts sind nun in folgender Reihenfolge implementiert:

1.

Der Rechner wird gestartet

2.

Die Netzwerkverbindung wird via selnic hergestellt und bei Erfolg wird die Unit network-is-connect.service angezogen

3.

Der User meldet sich an

4.

PAM startet /usr/local/bin/sessionctl

5.

sessionsctl startet mountctl.service, welches requires-depend zu serverctl.service ist

6.

serverctl.service startet /usr/local/bin/serverctl  und prüft die Erreichbarkeit des Samba-Servers 172.1.1.2

7.

Wenn der Samba-Server erreichbar ist, startet mountctl.service das Script /usr/local/bin/mountctl um letztendlich die Mounts für den angemeldeten User durchzuführen

Beim Shutdown des Rechners, bei der Abmeldung des Users vom System und beim Trennen von Netzwerkverbindungen via selnic -x werden immer vorher alle Remote-Mounts ordnungsgemäß geschlossen. Damit sind u.a. die 120-Sec-Stopjobs erfolgreich verhindert.

Hier folgend sind die beteiligten Prozesse einmal grafisch dargestellt:

 
 

Um nun noch mal auf die Eingangsfrage zurückzukommen "Muss das so kompliziert sein, geht das wirklich nicht einfacher?".... tja, keine Ahnung, ich weiß es nicht. Und ich bin dankbar für jede andere Lösung, die einfacher ist und trotzdem die oben beschriebenen Anforderungen erfüllt. Bis zur aktuellen Version 1.0 von mountctl hat es fast 3 Jahre gedauert. Es hat vorher 28 Versionen gegeben, die sich immer weiter entwickelt haben, aber immer irgendwie doch unvollkommen waren, manche wurde sogar ganz verworfen. Nebenbei hab ich haufenweise andere ebenfalls immer erfolglose Versuche gestartet. Solange also meine aktuelle Lösung so erfolgreich funktioniert und solange es keine wirklich gute Alternative gibt, werde ich wohl dabei bleiben.

Einige Schlussbemerkungen:

!

mountctl kann problemlos manuell im Terminal mit den Parametern start | stop | suspend | poweroff aufgerufen werden. Lediglich beim Aufruf mit start ist festzustellen, dass die nun quasi manuell durchgeführten Mounts jetzt natürlich beim Shutdown nicht ausdrücklich berücksichtigt werden können. Eine Ausnahme besteht, wenn das Netzwerk via selnic verbunden wurde und erneut via selnic im Shutdownprozess gemäß des Stop-Commands in der Unit mit -x beendet wird. In diesem Fall  werden die Remote-Mounts vor der Netzwerkstrennung ordentlich geschlossen.

!

selnic kann nicht konfliktfrei gleichzeitig mit dem dhcpd-Daemon und dem networkmanager-Daemon betrieben werden. Ich persönlich halte dhcpd und NWM sowieso für überflüssig, insofern beachte ich das auch nicht weiter.

!

Sollen die User selnic und mountctl auch interaktiv im Terminal aufrufen können, so erfolgt der Aufruf immer via pkexec. Gerade für selnic ist der Programmstart via Desktopstarter durchaus sinnvoll, um den Rechner beispielsweise mit einem fremden Gastgeber-WLAN-Netz zu verbinden. Beispiel für den Eintrag im Desktop-Starter:

/usr/bin/pkexec /usr/local/bin/selnic -n

oder für den manuellen Aufruf im User-Terminal mit einem Bash-Alias:

alias mountctl="/usr/bin/pkexec /usr/local/bin/mountctl"

alias selnic="/usr/bin/pkexec /usr/local/bin/selnic"

der dann den tatsächlichen 'einfachen' Aufruf im Terminal ermöglicht:

mountctl start|stop|suspend|poweroff

selnic

!

Für den interaktiven Start von mountctl durch den User empfehle ich das selnic-Menü zu verwenden. selnic startet nicht direkt das Script mountctl, sondern via systemctl die Unit mountctl.service. Damit ist gewährleistet, dass die Mounts beim Shutdown oder Trennen des Netzwerks nicht vergessen werden.

!

Das Script mountctl enthält oben am Anfang des Programms das leer initialisierte Array aMounts=(). Wenn dieses Array leer ist, wird die fstab gelesen und es werden von dort die entsprechenden Mounts übernommen. Das "wenn" bedeutet aber, das Array muss nicht leer sein. Es ist auch nicht zwingend notwendig, die Mounts in die fstab einzutragen. Aus Gründen einer flexibleren Handhabung und weil die fstabs sich sowieso alle durch lokale UUID's unterscheiden, pack ich die Client-fstab's heute gar nicht mehr an. Die fstab's sind immer unterschiedlich und eine Muster-fstab kann deshalb nicht ohne Nacharbeiten repliziert werden. Für unsere Remote-Mounts bestehen dem entgegen jedoch auf allen Clients identische Grundlagen bzw. Anforderungen. Also hinterlege ich die Remote-Mounts direkt im Script mountctl und verwende statt der leeren Arrayinitialisierung eine "zuweisende" Initialisierung (ohne Kommentare):

aMounts=(

    "//172.1.1.2/Disk_1      /media/Disk_1     cifs  credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/Disk_2      /media/Disk_2     cifs  credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async"    

    "//172.1.1.2/SSD_1       /media/SSD_1      cifs  credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async"    

    "//172.1.1.2/Install     /media/Install    cifs  credentials=/home/1000/.smbcred,uid=thomas,gid=thomas,rw,noauto,nosuid,nodev,noexec,nouser,async"    

    "//172.1.1.2/Buch        /media/Buch       cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/Film        /media/Film       cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/CD          /media/CD         cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/Downloads   /media/Downloads  cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/DatenAlle   /media/DatenAlle  cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,noexec,nouser,async"

    "//172.1.1.2/homes/Daten /home/1000/SHome  cifs  credentials=/home/1000/.smbcred,uid=1000,gid=1000,rw,noauto,nosuid,nodev,nouser,async"

)

 

Und das hat zur Folge, dass die Einrichtung eines PCs oder einer VM wenig mehr als nur das Kopieren einiger weniger Dateien an Aufwand bedeutet.

!

!

In den Programmen selnic und mountctl suche und identifiziere ich Remote-Mounts immer nach diesem "//" Doppelschrägstrich als Merkmal dafür, das es sich nicht um lokale Laufwerke handelt, sondern um Netzwerk-Laufwerke. Das heißt, in Umgebungen, in denen die entfernten Ressourcen anders genannt sind und die Namen nicht mit '//' beginnen, werden gewisse Funktionen nicht laufen. Hierfür wären Anpassungen in den Programmen notwendig. In diesem Fall dürfen die Programme nicht in Betrieb genommen werden!

< zurück >