mounten von Netzwerkgeräten per fstab

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 09:23:39

Hi,

ich habe hier hin und wieder das Problem, dass mein Rechner schneller gebootet hat, als das NAS.

Jetzt gibt es ja die mount-Option _netdev fuer Netzwerk-Geräte, die dafuer sorgt, dass diese Geräte von den Bootscripten erst gemoutet werden, wenn Netzwerk vorhanden ist.

Aber offenbar nehmen die Bootscripte es nicht sonderlich genau mit dem Vorhandensein oder nicht Vorhandensein von Ressourcen.

Und ich dachte ja, mit systemd wird alles besser :)

Es gelingt dennoch immer wieder, dass die '_netdev' Einträge in der fstab zu früh gemountet werden.

Ist unter debian jessie irgendwie eine Möglichkeit vorgesehen, die ich vieleicht übersehen habe, dass Netzwerk-Geräte, die in der fstab stehen, erst dann gemountet werden, wenn alle notwendigen ressourcen vorhanden sind? Oder gibt es im systemd die Möglichkeit, einen dienst bzw. einen Teilbaum von Dienstabhängigkeiten solange periodisch zu starten, bis er erfolgreich absolviert wurde?

Gruß

TomL

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 10:48:21

- mount.cifs kennt den Parameter _netdev nicht
- ist das Netzwerk komplett auf systemd umgestellt, existiert das Problem nicht
- trag als quick&dirty-Versuch folgendes in die rc.local ... vor dem exit:
sleep 5
mount -a

Eventuell musst du die 2 Befehle noch mit Pfaden vervollständigen. Die Fehlermeldungen beim booten bleiben, aber wenn sie einen nicht stören, kann man sie auch ignorieren. Aber die Mounts müssten danach bestehen.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 11:31:59

TomL hat geschrieben:- mount.cifs kennt den Parameter _netdev nicht
- ist das Netzwerk komplett auf systemd umgestellt, existiert das Problem nicht
- trag als quick&dirty-Versuch folgendes in die rc.local ... vor dem exit:
sleep 5
mount -a

Eventuell musst du die 2 Befehle noch mit Pfaden vervollständigen. Die Fehlermeldungen beim booten bleiben, aber wenn sie einen nicht stören, kann man sie auch ignorieren. Aber die Mounts müssten danach bestehen.
- _netdev ist kein dateisystemspezifischer sondern ein fstab Parameter und kann in der fstab bei jedem xbeliebigen Dateisystem angegeben werden. D.h. mount kennt den Parameter, und /etc/network/if-up.d/mountnfs und /etc/init.d/mountall.sh nutzen den Parameter in Zusammenhang mit 'mount -a'.

- /etc/network/if-up.d/mountnfs wird offenbar aus /etc/init.d/networking heraus aufgerufen und zwar indirekt per 'ifup -a ...'

- und /etc/network/if-up.d/mountnfs ruft dann 'mount -a -O _netdev', welches alle in der fstab enthaltenen per '_netdev' getaggten Einträge mountet.

Offenbar existiert keine Lösung für das Problem in Debian, ausser man baut sich selber eine.

Gruß

TomL

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 12:36:02

weedy hat geschrieben:- _netdev ist kein dateisystemspezifischer sondern ein fstab Parameter und kann in der fstab bei jedem xbeliebigen Dateisystem angegeben werden. D.h. mount kennt den Parameter, und /etc/network/if-up.d/mountnfs und /etc/init.d/mountall.sh nutzen den Parameter in Zusammenhang mit 'mount -a'.
Erzähl nicht so'n Quatsch... Du siehst doch, das es nicht funktioniert.... die Ursache ist doch offensichtlich. :wink:

Aus Man-Page mount:
For a few types however (like nfs, nfs4, cifs, smbfs, ncpfs) an ad hoc code is necessary. The nfs, nfs4, cifs, smbfs, and ncpfs filesystems have a separate mount program.
Aus Man-Page mount.cifs:
mount.cifs mounts a Linux CIFS filesystem. It is usually invoked indirectly by the mount(8) command when using the "-t cifs" option.
Schau selber nach, den Parameter _netdev gibts nicht:
https://www.samba.org/samba/docs/man/ma ... ifs.8.html
weedy hat geschrieben:Offenbar existiert keine Lösung für das Problem in Debian, ausser man baut sich selber eine.
Natürlich gibts eine Lösung, einfach nicht die alten (imho überflüssigen) sysvinit-Scripts nutzen, sondern auf systemd umstellen. Und bei Verwendung von systemd-networkd die fstab-Option "x-systemd.requires=systemd-networkd-wait-online.service" verwenden. Das bedeutet, bisher nutzt du überhaupt nicht die Möglichkeiten, die vom aktuellen Debian genau dafür vorgesehen sind. Ganz nebenbei bemerkt, ist die fstab mit systemd sowieso überflüssig, mount-units sind der bessere Weg.... aber momentan wird die fstab halt noch von systemd zusätzlich interpretiert.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 13:57:32

TomL hat geschrieben:
Schau selber nach, den Parameter _netdev gibts nicht:
https://www.samba.org/samba/docs/man/ma ... ifs.8.html
Ich hatte es oben eigentlich korrekt erklaert, aber fuer Dich nochmal:

mount -a ... mountet alle in der fstab enthaltenen Eintraege, in denen die Option noauto nicht gegeben ist (nur nebenbei: noauto ist auch eine fstab und keine Dateisystem-Option)

Code: Alles auswählen


aus mount(8):

       -a, --all
              Mount  all  filesystems  (of the given types) mentioned in fstab
              (except for those whose line contains the noauto keyword).   The
              filesystems are mounted following their order in fstab.
mount -a -O _netdev ... mountet alle in der fstab enthaltenen Eintraege, in denen die Option noauto und _netdev gegeben sind

mount -a -O no_netdev ... mountet alle in der fstab enthaltenen Eintraege, in denen die Option noauto gegeben ist und _netdev nicht ist

Code: Alles auswählen


aus mount(8):

       -O, --test-opts opts
              Limit the set of filesystems to which the -a option applies.  In
              this  regard  it is like the -t option except that -O is useless
              without -a.  For example, the command:

                     mount -a -O no_netdev

              mounts all filesystems except those which have the option  _net‐
              dev specified in the options field in the /etc/fstab file.

              It  is different from -t in that each option is matched exactly;
              a leading no at the beginning of one option does not negate  the
              rest.

              The  -t  and  -O  options are cumulative in effect; that is, the
              command

                     mount -a -t ext2 -O _netdev

              mounts all ext2 filesystems with the  _netdev  option,  not  all
              filesystems  that  are  either  ext2  or have the _netdev option
              specified.


Und damit ist klar, dass Du in den falschen manpages nach einem Parameter gesucht hast, denn _netdev ist nicht dem Dateisystem (Du hast Dateisystem-Manpages zitiert), sondern dem mount-Verhalten bzgl. der /etc/fstab zuzuordnen.

Es gibt also, um das nochmals zu verdeutlichen in der /etc/fstab pro Eintrag eine Stelle (Feld 4), in der sich 2 Sorten von Optionen befinden können: Dateisystem-Optionen, die dem Dateisystem zuzuordnen sind und fstab bzw. mount-Optionen, die nicht mit dem Dateisystem zu tun haben, sondern mit der Art und weise, wie 'mount -a' und 'mount -a -O ...' sich verhält.

Code: Alles auswählen


aus fstab(5)

       The fourth field (fs_mntops).
              This field describes the mount options associated with the filesystem.

              It  is  formatted as a comma separated list of options.  It contains at least the type of
              mount plus any additional options appropriate to the filesystem type.  For  documentation
              on  the  available  mount options, see mount(8).  For documentation on the available swap
              options, see swapon(8).

              Basic file system independent options are:

              defaults
                     use default options: rw, suid, dev, exec, auto, nouser, and async.

              noauto do not mount when "mount -a" is given (e.g., at boot time)

              user   allow a user to mount

              owner  allow device owner to mount

              comment
                     or x-<name> for use by fstab-maintaining programs

              nofail do not report errors for this device if it does not exist.




Gruß

TomL

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 14:21:37

Bin jetzt mit tapatalk und deshalb leider mit eingeschränkten Möglichkeiten unterwegs. Also akzeptiere ich jetzt einfach mal deine Behauptung, dass meine Interpretation der Man-Pages falsch ist.

An der Stelle gibts jetzt nur noch ein ungeklärtes Problem .... und zwar die Tatsache, dass _netdev die Frechheit hat, trotz deiner Behauptung nicht zu funktionieren. Könntest du diesen Widerspruch eben noch kurz erklären... vor dem Hintergrund, dass weder in mount, noch in networking, noch in systemd und auch nicht in Debian allgemein an der Stelle ein Fehler vorliegt.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 14:36:58

TomL hat geschrieben:Bin jetzt mit tapatalk und deshalb leider mit eingeschränkten Möglichkeiten unterwegs. Also akzeptiere ich jetzt einfach mal deine Behauptung, dass meine Interpretation der Man-Pages falsch ist.

An der Stelle gibts jetzt nur noch ein ungeklärtes Problem .... und zwar die Tatsache, dass _netdev die Frechheit hat, trotz deiner Behauptung nicht zu funktionieren. Könntest du diesen Widerspruch eben noch kurz erklären... vor dem Hintergrund, dass weder in mount, noch in networking, noch in systemd und auch nicht in Debian allgemein an der Stelle ein Fehler vorliegt.
Also ich habe auf meinem System gerade folgendes ausprobiert:

umount -av -O _netdev ... es wurden alle netzlaufwerke ge-umountet

mount -av -O _netdev ... es wurden alle netzlaufwerke gemountet

Hat alles also funktioniert.

Nur ist das nicht der Kern meines ursprünglichen Problems.

Gruß

TomL

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 14:45:05

weedy hat geschrieben:Also ich habe auf meinem System gerade folgendes ausprobiert:

umount -av -O _netdev ... es wurden alle netzlaufwerke ge-umountet

mount -av -O _netdev ... es wurden alle netzlaufwerke gemountet
Äh, wie testet man denn umount in der bootphase? Du überrascht mich wirklich ...
Und das das zur Laufzeit ohne Fehlermeldung klappt, ist doch selbstverständlich... das Netzwerk ist verfügbar, _netdev wird hier und bei cifs ebenfalls ignoriert.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: AW: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 15:56:15

TomL hat geschrieben:
weedy hat geschrieben:Also ich habe auf meinem System gerade folgendes ausprobiert:

umount -av -O _netdev ... es wurden alle netzlaufwerke ge-umountet

mount -av -O _netdev ... es wurden alle netzlaufwerke gemountet
Äh, wie testet man denn umount in der bootphase? Du überrascht mich wirklich ...
Und das das zur Laufzeit ohne Fehlermeldung klappt, ist doch selbstverständlich... das Netzwerk ist verfügbar, _netdev wird hier und bei cifs ebenfalls ignoriert.
Es ist völlig egal, ob irgendein Dateisystem die Option _netdev kennt, genaugenommen wäre es sogar semantisch falsch, wenn irgendein Dateisystem _netdev kennen würde, denn _netdev richtet sich an mount zur Interpretation der Datei /etc/fstab.

Aber mount selber berücksichtigt _netdev, so, wie es sein soll.

Deswegen ist es völlig unerheblich, ob cifs _netdev kennt oder nicht. mount muss es kennen! Und das tut es:

Code: Alles auswählen


/*
 * userspace mount option (built-in MNT_USERSPACE_MAP)
 */
static const struct libmnt_optmap userspace_opts_map[] =
{
   { "defaults", 0, 0 },               /* default options */

   { "auto",    MNT_MS_NOAUTO, MNT_NOHLPS | MNT_INVERT | MNT_NOMTAB },  /* Can be mounted using -a */
   { "noauto",  MNT_MS_NOAUTO, MNT_NOHLPS | MNT_NOMTAB },  /* Can only be mounted explicitly */

   { "user[=]", MNT_MS_USER },                             /* Allow ordinary user to mount (mtab) */
   { "nouser",  MNT_MS_USER, MNT_INVERT | MNT_NOMTAB },    /* Forbid ordinary user to mount */

   { "users",   MNT_MS_USERS, MNT_NOMTAB },                /* Allow ordinary users to mount */
   { "nousers", MNT_MS_USERS, MNT_INVERT | MNT_NOMTAB },   /* Forbid ordinary users to mount */

   { "owner",   MNT_MS_OWNER, MNT_NOMTAB },                /* Let the owner of the device mount */
   { "noowner", MNT_MS_OWNER, MNT_INVERT | MNT_NOMTAB },   /* Device owner has no special privs */

   { "group",   MNT_MS_GROUP, MNT_NOMTAB },                /* Let the group of the device mount */
   { "nogroup", MNT_MS_GROUP, MNT_INVERT | MNT_NOMTAB },   /* Device group has no special privs */

   /*
    * Note that traditional init scripts assume the _netdev option in /etc/mtab to
    * umount network block devices on shutdown.
    */
   { "_netdev", MNT_MS_NETDEV },                           /* Device requires network */

...

(optmap.c, libmount)

Dennoch berücksichtigt der Bootvorgang _netdev in dem Sinne, dass Netzlaufwerke zu einem anderen Zeitpunkt (wie ich es oben bereits erklärte) mountet. Insbesondere werden Netzlaufwerke erst dann gemountet, wenn eine Bedingung erfüllt ist, nämlich die, dass das Netzwerk im lokalen Rechner verfügbar ist.

Leider aber erfolgt auf meinem System das mounten der Netzlaufwerke (durch mount -n -O _netdev) implizit bei vorhandensein des Netzwerks, so dass keine weitere Bedingungen im systemd-Stil angegeben werden können, um die Netzlaufwerke zu mounten.

Also ist der Schritt des mountens von Netzlaufwerken nicht separierbar und nicht korrigierbar im systemd-Stil.

Nun könnte es ja sein (was ich mal annehme), dass systemd das wiederholte starten eines Dienstes erlaubt, bis es endlich geglückt ist, oder auch, dass man weitere Bedingungen mit in ein moeglicherweise vorhandenen systemd-dienst einfuegt, der sich ausschliesslich um das mounten von Netzlaufwerken kümmert, aber derzeit ist mein System nicht so aufgebaut und ich habe ehrlichgesagt bedenken, dass eine Modifikation von meiner Seite (ich muesste dazu einen Dienst einrichten und das ifup-Script ggf. modifizieren) zu einer Kollision mit der Systemverwaltung des Debian Paket Managers führt.

Deswegen fragte ich ganz zu beginn, ob es vieleicht eine einfachere Lösung gibt.

Die könnte es natürlich geben, wenn ein Paket existieren würde, welches so einen Dienst zur Verfügung stellt, welcher entweder nach Prüfung weiterer Vorbedingungen oder wiederholend oder beides den 'mount -a -O ...' Befehl absetzt.

Aber wie schon gesagt, ich nehme an, dass eine solche Lösung nicht existiert, also muss ich mich kümmern.

Gruß

TomL

Re: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 16:23:11

Also ist der Schritt des mountens von Netzlaufwerken nicht separierbar und nicht korrigierbar im systemd-Stil.
Sorry... aber ich komme mit deinen Schlussfolgerungen überhaupt nicht klar.... ich glaube, dass Du ziemlich weit neben der Wahrheit liegst.... vor allem vor dem Hintergrund, das mount.c selber gar nicht mountet, und das Dein Problem real ist, aber trotzdem keinen Fehler darstellt. Das ganze Verhalten ist Man-Page-Konform. Und was ist denn eigentlich ein systemd-Stil...?... du nutzt doch gar keinen Systemd-Stil (mount-units oder systemd-networkd) und dann das von mir vorgeschlagene Requieres-Statement in der fstab.

BTW: ich habe nie behauptet, dass mount den Parameter_netdev nicht kennt und den in gegebenen Fällen nicht auch berücksichtigt... ich behaupte nur, dass mount bei Erkennen von cifs überhaupt nix tut, sondern das Geschäft einfach an mount.cifs weitergibt. Und natürlich kennt auch mount.cifs den Parameter _netdev, aber hier ist m.E. eindeutig dokumentiert, was es damit macht:

https://git.samba.org/?p=cifs-utils.git ... b531d858e6

Code: Alles auswählen

686 static int parse_opt_token(const char *token)
687 {
688         if (token == NULL)
689                 return OPT_ERROR;
690
691         if (strncmp(token, "users", 5) == 0)
692                 return OPT_USERS;
693         if (strncmp(token, "user_xattr", 10) == 0)
694                 return OPT_USER_XATTR;
695         if (strncmp(token, "user", 4) == 0)
696                 return OPT_USER;
697         if (strncmp(token, "pass", 4) == 0)
698                 return OPT_PASS;
699         if (strncmp(token, "sec", 3) == 0)
700                 return OPT_SEC;
701         if (strncmp(token, "ip", 2) == 0)
702                 return OPT_IP;
703         if (strncmp(token, "unc", 3) == 0 ||
704                 strncmp(token, "target", 6) == 0 ||
705                 strncmp(token, "path", 4) == 0)
706                 return OPT_UNC;
707         if (strncmp(token, "dom", 3) == 0 || strncmp(token, "workg", 5) == 0)
708                 return OPT_DOM;
709         if (strncmp(token, "cred", 4) == 0)
710                 return OPT_CRED;
711         if (strncmp(token, "uid", 3) == 0)
712                 return OPT_UID;
713         if (strncmp(token, "cruid", 5) == 0)
714                 return OPT_CRUID;
715         if (strncmp(token, "gid", 3) == 0)
716                 return OPT_GID;
717         if (strncmp(token, "fmask", 5) == 0)
718                 return OPT_FMASK;
719         if (strncmp(token, "file_mode", 9) == 0)
720                 return OPT_FILE_MODE;
721         if (strncmp(token, "dmask", 5) == 0)
722                 return OPT_DMASK;
723         if (strncmp(token, "dir_mode", 4) == 0 || strncmp(token, "dirm", 4) == 0)
724                 return OPT_DIR_MODE;
725         if (strncmp(token, "nosuid", 6) == 0)
726                 return OPT_NO_SUID;
727         if (strncmp(token, "suid", 4) == 0)
728                 return OPT_SUID;
729         if (strncmp(token, "nodev", 5) == 0)
730                 return OPT_NO_DEV;
731         if (strncmp(token, "nobrl", 5) == 0 || strncmp(token, "nolock", 6) == 0)
732                 return OPT_NO_LOCK;
733         if (strncmp(token, "mand", 4) == 0)
734                 return OPT_MAND;
735         if (strncmp(token, "nomand", 6) == 0)
736                 return OPT_NOMAND;
737         if (strncmp(token, "dev", 3) == 0)
738                 return OPT_DEV;
739         if (strncmp(token, "noexec", 6) == 0)
740                 return OPT_NO_EXEC;
741         if (strncmp(token, "exec", 4) == 0)
742                 return OPT_EXEC;
743         if (strncmp(token, "guest", 5) == 0)
744                 return OPT_GUEST;
745         if (strncmp(token, "ro", 2) == 0)
746                 return OPT_RO;
747         if (strncmp(token, "rw", 2) == 0 && strlen(token) == 2)
748                 return OPT_RW;
749         if (strncmp(token, "remount", 7) == 0)
750                 return OPT_REMOUNT;
751         if (strncmp(token, "_netdev", 7) == 0)
752                 return OPT_IGNORE;
753         if (strncmp(token, "backupuid", 9) == 0)
754                 return OPT_BKUPUID;
755         if (strncmp(token, "backupgid", 9) == 0)
756                 return OPT_BKUPGID;
757         if (strncmp(token, "nofail", 6) == 0)
758                 return OPT_NOFAIL;
759
760         return OPT_ERROR;
761 }
Aber Du kannst natürlich weiter an einem Problem festhalten, was eigentlich keins ist.... Debian macht jedenfalls alles richtig.....

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 16:40:23

TomL hat geschrieben: Aber Du kannst natürlich weiter an einem Problem festhalten, was eigentlich keins ist.... Debian macht jedenfalls alles richtig.....
Das grenzt natürlich fast schon an einer rein philosphischen Frage, nämlich der, was genau richtig ist, und was nicht.

In dem Sinne, dass der Computer grundsätzlich alles richtig macht, weil er einfach nicht anders kann, als die gegebenen Bits so zu interpretieren, wie es in seiner Spezifikation vorgesehen ist, ...

Aber das ist leider nicht zielführend. Natürlich, Debian macht beim Bootvorgang exakt das, was in den Bootscripten drinsteht, vorausgesetzt, sie werden auch aufgerufen. Und natürlich mach mein Debian zu gegebenem Anlass auch ein 'mount -a -O _netdev', nur leider zu einem Zeitpunkt, in dem das NAS noch nicht zu 100% fertig gebootet hat.

Debian hat bis dahin alles richtig gemacht. mount hat die Option _netdev korrekt interpretiert, cifs hat diese Option korrekt ignoriert, aber trotz all der schönen Dinge, die auf wundersame Weise geschehen sind, bin ich mit dem Endergebnis nicht zu 100% zufrieden.

Und zwar einfach aus dem Grund, weil ich zuweilen nach dem Bootvorgang des Rechners nicht auf das NAS zugerifen kann.

Und jetzt die alles entscheidende Frage: wie schaffe ich es (ob es ein Problem oder die Darstellung eines Problems ist, oder nicht, sei dahingestellt) dass mein Rechner nach dem Booten immer (und nicht nur gelegentlich) auf das NAS zugreifen kann?

Gruß

TomL

Re: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 17:36:41

weedy hat geschrieben:Das grenzt natürlich fast schon an einer rein philosphischen Frage, nämlich der, was genau richtig ist, und was nicht.
Richtig ist das, was das System tut... und erst in zweiter Instanz, was in den Man-Pages steht... so sinngemäß soll das Pöttering gesagt haben. Aber hier und in diesem besonderen Fall stimmen Verhalten und Beschreibung eindeutig überein.

Die Lösung ist doch einfach...und es gibt sogar verschiedene Wege....wobei alle damit anfangen, dass Du zu allererst akzeptierst, dass "_netdev" nicht für Remote-FS gedacht ist und für Dein Problem schlicht unwirksam ist.... was u.a. auch Rendegast schon mal vor Monaten hier festgestellt hat.

Der einfachste und erste Lösungsvorschlag wäre, auf systemd-networkd umzustellen. Dann kannst Du die fstab für diese Fälle vergessen und stattdessen simple mount-units verwenden, die z.B. so aussehen... damit ist der Fehler Geschiche:

Code: Alles auswählen

nano /etc/systemd/system/media-HD_2.mount

Code: Alles auswählen

[Unit]
Description=Mount Network-Drives
Requires=systemd-networkd-wait-online.service
After=systemd-networkd-wait-online.service
ConditionPathExists=/media/HD_2

[Mount]
What=//10.1.1.2/HD_2
Where=/media/HD_2 
Options=credentials=/home/thomas/.smbcredentials,uid=thomas,gid=thomas,rw,nosuid,nodev,noexec,async
Type=cifs

[Install]
WantedBy=multi-user.target
Die zweite Möglichkeit besteht darin, auch auf systemd-networkd umzustellen und bei den Remote-FS in der fstab als Option

Code: Alles auswählen

x-systemd.requires=systemd-networkd-wait-online.service
an die bestehenden Optionen anzufügen. Damit spart man sich die mount-units und kann die alte fstab (vorübergehend noch?) nutzen

Dir dritte Möglichkeit besteht darin, speziell die Remote-FS-Mounts in ein Bashscript auszulagern, in dem zuerst aufs Netzwerk und dann auf den Server gewartet wird, um dann zu mounten. Dieses Bash-Script wird natürlich über eine system-service-unit beim Booten gestartet. Bei dieser Lösung spart man sich den Wechsel von networking auf systemd-networkd.

Eine vierte Möglichkeit besteht darin, eine eigene network-wait-online.service-unit zu schreiben, mit der du dann die Lösung 1 und 2 verwenden kannst, ohne auf systemd-networkd umzustellen. Lösung 3 könnte das ebenfalls in seiner Service-Unit verwenden und benötigt dafür dann keine eigenen Routinen mehr. Das (3 und 4) ist bisher meine Lösung, weil ich die Mounts (ein Bash-Script (/usr/local/bin/mountctl) für alle Systeme) Geräte- und Userspezifisch mit Conditions versehen habe.... obowhl ich auch auf systemd-networkd umgestellt habe. Aber mein network-wait-online.service prüft auch den Server, der immer eine gewisse Zeit braucht, bis er die tiefschlafende HD geweckt hat.

Alle 4 Lösungen warten vor dem Mount der Remote-FS aufs Netzwerk, die 3. und 4. sogar auf den Server... die Fehler sind damit Vergangenheit.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 20:48:27

TomL hat geschrieben:...
Danke erstmal für die Inspiration, ich hatte nicht gewusst, dass sich systemd explizit um mounts kümmern kann. Ich werde mir das definitiv genauer ansehen.

Aber eine Frage beschäftigt mich immer noch. Warum hast Du immerzu betont, dass '_netdev' von cifs nicht berücksichtigt wird?

Gruß

TomL

Re: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 21:08:37

weedy hat geschrieben:Aber eine Frage beschäftigt mich immer noch. Warum hast Du immerzu betont, dass '_netdev' von cifs nicht berücksichtigt wird?
Weil diese Aussage falsch ist:
weedy hat geschrieben:Jetzt gibt es ja die mount-Option _netdev fuer Netzwerk-Geräte, die dafuer sorgt, dass diese Geräte von den Bootscripten erst gemoutet werden, wenn Netzwerk vorhanden ist.
Ganz offensichtlich tut _netdev das nämlich in Deinem Fall nicht...(ebensowenig wie früher bei mir) ... und es tut es deshalb nicht, weil es eben nicht für Remote-FS (hier cifs) gedacht ist und dementsprechend in mount.cifs schlichtweg ignored wird. Aber wenn ich ehrlich bin, ich habe auch noch nicht so richtig kapiert, wo man das überhaupt benötigt.... genau dafür habe ich bisher nämlich noch keine Erklärung finden können.

Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

Re: mounten von Netzwerkgeräten per fstab

Beitrag von weedy » 01.05.2016 21:15:14

TomL hat geschrieben:
weedy hat geschrieben:Aber eine Frage beschäftigt mich immer noch. Warum hast Du immerzu betont, dass '_netdev' von cifs nicht berücksichtigt wird?
Weil diese Aussage falsch ist:
weedy hat geschrieben:Jetzt gibt es ja die mount-Option _netdev fuer Netzwerk-Geräte, die dafuer sorgt, dass diese Geräte von den Bootscripten erst gemoutet werden, wenn Netzwerk vorhanden ist.
Ganz offensichtlich tut _netdev das nämlich in Deinem Fall nicht...(ebensowenig wie früher bei mir) ... und es tut es deshalb nicht, weil es eben nicht für Remote-FS (hier cifs) gedacht ist und dementsprechend in mount.cifs schlichtweg ignored wird. Aber wenn ich ehrlich bin, ich habe auch noch nicht so richtig kapiert, wo man das überhaupt benötigt.... genau dafür habe ich bisher nämlich noch keine Erklärung finden können.
Wäre denn die Aussage richtig, wenn ich sie so umformuliere:

"Jetzt gibt es ja die mount-Option _netdev fuer Netzwerk-Geräte, die dafuer sorgt, dass diese Geräte von den Bootscripten erst versucht werden gemoutet zu werden, wenn Netzwerk vorhanden ist."

?

Und ich schreibe das aus folgendem Grund: immerhin wird der Befehl 'mount -a -O _netdev' erst abgesetzt, nachdem Netzwerk vorhanden ist. Ob er jedoch gelingt, hängt von anderen Faktoren ab. Und damit untersuchen wir letztendlich, ob die Aussage, dass etwas gemountet wird auch dann gültig ist, wenn nur der Versuch des mountens unternommen wird, dieser aber fehlschlägt. Denn, so meine ich, davon hängt letztendlich ab, ob mein von Dir beanstandeter Satz tatsächlich falsch oder richtig ist, und dann nur wegen dieses einen schon wieder philosophischen Unterscheidungsmerkmales. Immerhin befinden wir uns damit immer noch im Bereich des Aussagenkalküls und damit in der Informatik - nichts für ungut.

Gruß

TomL

Re: mounten von Netzwerkgeräten per fstab

Beitrag von TomL » 01.05.2016 21:45:36

Die Aussage ist doch die gleiche. Mein Problem ist, dass ich nicht wirklich die Bedeutung von _netdev verstehe.

Heisst das wirklich:
Diese Mount-Ressource kommt aus dem Netzwerk!

Oder heisst das vielleicht auch nur:
Diese Mount-Ressource benötigt das Netzwerk!

Und das vor dem Hintergrund, dass "Netzwerk ist gestartet" noch lange nicht "Netzwerk ist verfügbar" bedeutet, sondern vielleicht nur "Netzwerkmanager wurde gestartet". Und "Netzwerk ist verfügbar" bedeutet ebenfalls noch lange nicht "Netzwerk ist verbunden", sondern nur dass die Interfaces erkannt und geöffnet wurden. Da kanns immer noch auf DHCP warten. Und es bedeutet schon mal gar nicht, dass eine noch hinter dem Netzwerk vorhande notwendige Ressource (ein entfernter Server) verfügbar ist. Also ganz so einfach ist das mit dem _netdev nicht. Wenn Du Deinen Zustand von _netdev definierst, definiere ich dir drei andere, die ebenfalls richtig sind.... nur eben anders, als du denkst.

Und Du darfst nicht vergessen, dass wir mit der unnötigen Übernahme der fstab und networking nach Jessie unter typischen Migrationssünden beim Wechsel von sysvinit nach systemd leiden. Früher unter starrer sysvinit-Boot-Reihenfolge gabs solche Probleme wahrscheinlich nicht. Jetzt, wo systemd alles gleichzeitig startet, passiert das eben.... eben deshalb, weil dieser alte unangepasste Kram immer noch mitläuft. Schmeiss das raus und du hast keine Probleme mehr.

Antworten