[gelöst] Ubuntu 20.04 kein NFS Mount per fstab

  • Moin moin!


    Leider erlaubt mir das systemd - Gefrickel nicht mehr den einfachen Weg, mein Videodir per fstab beim booten vom NAS zu mounten. Irgendwie sind die Abhängigkeiten dort nicht so, wie man sich das vorstellen würde, und eine rc.local wo man einfach ein mount -a; touch .update hinterlegen könnte, hat sich auch noch nicht gefunden.


    Wer würde einem Nicht-Systemd-bewanderten dort mal auf die Sprünge helfen?

    Umgebung: Ubuntu 20.04 minimal mit yavdr-experimental Paketen als headless-Server.


    Bereits versucht: alle möglichen Mount-Optionen mit _netdev und x-automount-wasweißich, eigene SystemD Units, die dann auch das Verzeichnis gemountet haben, aber leider zu spät für VDR, etc.


    Das muß doch einfacher gehen. Habe jetzt schon ein paar Stunden verbrannt, einen früher einfachen Einzeiler in diese systemd-Logik zu bekommen.

  • eine rc.local wo man einfach ein mount -a; touch .update hinterlegen könnte, hat sich auch noch nicht gefunden.

    Die gibt es zwar nicht, die kann man aber anlegen und wird dann auch von systemd ausgeführt. Das ist aber nicht "recommended".


    Diese systemd mount Unit läuft bei mir:

    Der Name muss der Unit muss der Ausgabe von

    Code
    systemd-escape --suffix=mount --path <EINHÄNGEPUNKT> 

    entsprechen.

  • Klappt leider nicht, Netzwerk ist wohl doch noch nicht "richtig" da, wenn das Target erreicht wird


    Feb 13 23:40:38 server systemd[1]: Reached target Network is Online.

    Feb 13 23:40:38 server systemd[1]: Mounting NFS mount unit...

    Feb 13 23:40:39 server mount[547]: mount.nfs: Network is unreachable

    Feb 13 23:40:39 server systemd[1]: srv-vdr-video.mount: Mount process exited, code=exited, status=32/n/a

    Feb 13 23:40:39 server systemd[1]: srv-vdr-video.mount: Failed with result 'exit-code'.

    Feb 13 23:40:39 server systemd[1]: Failed to mount NFS mount unit.


    Die Unit an sich funktioniert, wenn ich sie später manuell aufrufe.

  • Hallo,


    und eine rc.local wo man einfach ein mount -a; touch .update hinterlegen könnte, hat sich auch noch nicht gefunden.

    die Datei "rc-local.service" kommt nach /etc/systemd/system

    Code
    sudo chown root:root /etc/systemd/system/rc-local.service
    sudo chmod 0644 /etc/systemd/system/rc-local.service

    Datei "rc.local" kommt nach /etc

    Code
    chown root:root /etc/rc.local
    chmod 0755 /etc/rc.local

    Service aktivieren:

    Code
    systemctl enable rc-local.service

    ** Die Ausgaben kannst du ignorieren **

    Service starten und Status abfragen:

    Code
    systemctl start rc-local.service
    systemctl status rc-local.service

    Hier sollte dann am Schluss sowas stehen

    ....systemd[1]: Starting /etc/rc.local Compatibility...

    ....systemd[1]: Started /etc/rc.local Compatibility.


    Dateien "rc-local.service & rc.local" im Anhang!

    rc-local.tar.gz


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

  • Es kann so einfach sein...


    Vielen Dank!



    #!/bin/bash

    #

    # rc.local

    #

    # This script is executed at the end of each multiuser runlevel.

    # Make sure that the script will "exit 0" on success or any other

    # value on error.

    #

    # In order to enable or disable this script just change the execution

    # bits.

    #

    # By default this script does nothing.


    sleep 5

    mount -a

    touch /srv/vdr/video/.update


    exit 0

  • ich mache meinen NFS-Mount in Ubuntu 20.04 aus der fstab so....

    Code
    ServerIP:/Freigabe_Ordner /Zielordner/weiter/noch_einer nfs auto,rw,vers=3,fg,nofail,noatime,nolock,tcp,actimeo=1800 0 0

    Voraussetzung .... NFSv3-Freigabe muss auf dem NAS / Server eingestellt sein ....



    wenn du die systemd-Services analysieren möchtest:


    Code
    systemd-analyze plot > /tmp/analysergebnis.html

    dann kannst Du Dir sehr schön den Ablauf der Systemservices ansehen ...und in den Services über die Anpassung der Optionen ..... das Timing beim Starteb deines VDR-Rechners anpassen ....

    --------------------------------------------------------------------------------------------------------------------------------------------------

    BM2LTS im VDR-Portal   http://www.bm2lts.de   http://www.sc-schulze.de

    --------------------------------------------------------------------------------------------------------------------------------------------------

    Empfang: Octopus Net S2 max (8 Tuner) + Octopus Net S2 max (8 Tuner) + Netceiver (2x DVB-s2dual)

    Kopfstation: Virtuelle Maschine mit BM2LTS v3.4.XX

    Clients: NUC10i5FNH2 -> BM2LTS v3.4.XX; FireTV4k mit Kodi u. VNSI-Plugin

    NAS: Aufnahmen u. Plex-Media

    --------------------------------------------------------------------------------------------------------------------------------------------------


  • Und eben genau das funktioniert nicht, höchstwahrscheinlich weil das network-online.target zu früh „fertig“ meldet, s.o.


    Der Workaround mit der rc.local funktioniert erstmal, hat aber vermutlich ein anderes Problem: wenn VDR vorher losläuft, und einen Timer startet, ist das Videoverzeichnis schon „busy“, der Mount wird dann auch fehlschlagen, und mir läuft die System-SSD voll.

  • Autostart von vdr abschalten und manuell in der rc.local starten.


    Oder doch die empfohlenen Methoden nehmen ...

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Bei mir läuft es wie bei kfb77

    Nur reichte es bei mir nicht mir network-online.taget.

    Hier ging es nur mit After=network.target

  • Hier ging es nur mit After=network.target

    Dass das was verbessert, verstehe ich nicht, da network.target vor network-online.target kommt. Die Wege von systemd sind manchmal seltsam ...


    Zitat
    • network.target has very little meaning during start-up. It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined. Its primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off. This allows services to cleanly terminate connections before going down, instead of abruptly losing connectivity for ongoing connections, leaving them in an undefined state. Note that network.target is a passive unit: you cannot start it directly and it is not pulled in by any services that want to make use of the network. Instead, it is pulled in by the network management service itself. Services using the network should hence simply place an After=network.target dependency in their unit files, and avoid any Wants=network.target or even Requires=network.target.
    • network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network is set up. It is an active target, meaning that is may be pulled in by the services requiring the network to be up, but is not pulled in by the network management service itself. By default all remote mounts defined in /etc/fstab pull this service in, in order to make sure the network is up before it is attempted to connect to a network share. Note that normally, if no service requires it, and if no remote mount point is configured this target is not pulled into the boot, thus avoiding any delays during boot should the network not be available. It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), its primary purpose is network client software that cannot operate without network.

    Quelle

  • Welche wären das? Die oben empfohlene Unit funktioniert nicht, ebenso wenig wie die Option in der fstab. Bin etwas ratlos ...

    Schon die Mount Unit ... hast Du mal geschaut, warum das NFS Verzeichnis nicht montiert wird?


    Kann es sein, das der hostname innerhalb systemd noch nicht aufgelöst werden kann?


    Mount Unit unter /etc/systemd/system erstellen. Lautet das Zielverzeichnis des NFS Mounts /srv/video, heißt die Datei /etc/systemd/system/srv-video.mount. Mount Options ändere ich z.B. nur minimal Options=auto,rw,soft ...


    Nun ein beherztes sudo systemctl daemon-reload, danach sudo systemctl enable srv-video.mount, der Name kann bei Dir natürlich anders sein ... zum Schluß sudo reboot.


    Nach dem Reboot per sudo systemctl status srv-video.mount nachschauen was falsch läuft. Relativ häufig scheint wohl die Namensauflösung im systemd Prozess nicht korrekt zu funktionieren.


    Dann entweder die IP Adresse des NFS Servers in die Mount systemd Mount Unit reinschreiben, nicht den hostname.


    Oder eben eine Zeile in der /etc/nsswitch.conf anpassen:


    hosts: resolve files mdns4_minimal [NOTFOUND=return] dns


    => genauer, hier resolve als ersten Eintrag einfügen ...

    HowTo: APT pinning

  • Das network-online.target ist definitiv "defekt", und das ist IMHO auch das Problem. Es wird zu früh gestartet, hier zwei Sekunden, bevor NetworkManager einen Link hat. Die .mount - Unit wird aus der fstab autogeneriert. Auf Ubuntu 18.04 war das alles kein Problem, lief sofort OOTB. Sieht auch alles genauso aus, was die dependencies etc. angeht. Den NetworkManager hatte ich testhalber mal Installiert, macht aber auch ohne keinen Unterschied.


    Feb 14 09:53:51 server systemd[1]: Reached target Network is Online.

    Feb 14 09:53:51 server systemd[1]: Mounting /srv/vdr/video...

    Feb 14 09:53:51 server mount[670]: mount.nfs: Network is unreachable

    Feb 14 09:53:51 server systemd[1]: srv-vdr-video.mount: Mount process exited, code=exited, status=32/n/a

    Feb 14 09:53:51 server systemd[1]: srv-vdr-video.mount: Failed with result 'exit-code'.

    Feb 14 09:53:51 server systemd[1]: Failed to mount /srv/vdr/video.

    Feb 14 09:53:51 server systemd[1]: Dependency failed for Remote File Systems.

    Feb 14 09:53:51 server systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.

    Feb 14 09:53:53 server systemd-networkd[326]: enp3s0: Gained carrier

    Feb 14 09:53:53 server NetworkManager[533]: <info> [1613292833.7330] device (enp3s0): carrier: link connected

    Feb 14 09:53:53 server systemd-timesyncd[527]: Network configuration changed, trying to establish connection.

    Feb 14 09:53:53 server systemd-timesyncd[527]: Initial synchronization to time server 91.189.89.198:123 (ntp.ubuntu.com).


    root@server:~# systemctl list-dependencies srv-vdr-video.mount

    srv-vdr-video.mount

    ● ├─-.mount

    ● ├─system.slice

    ● └─network-online.target

    ● ├─NetworkManager-wait-online.service

    ● └─systemd-networkd-wait-online.service

  • Ich mache das immer noch mittels Eintag in der fstab und hatte da bisher keine Timingprobleme:


    Code
    # openmediavault NFS exports
    10.205.1.147:/export/vdr /srv/vdr/video nfs defaults,auto,rw,_netdev,x-systemd.automount 0 0

    Cheers,

    Ole

  • Nachlieferung für fnu:


    root@server:~# systemctl status srv-vdr-video.mount

    ● srv-vdr-video.mount - /srv/vdr/video

    Loaded: loaded (/etc/fstab; generated)

    Active: failed (Result: exit-code) since Sun 2021-02-14 12:55:58 CET; 31s ago

    Where: /srv/vdr/video

    What: 192.168.1.55:/volume2/video

    Docs: man:fstab(5)

    man:systemd-fstab-generator(8)


    Feb 14 12:55:58 server systemd[1]: Mounting /srv/vdr/video...

    Feb 14 12:55:58 server mount[678]: mount.nfs: Network is unreachable

    Feb 14 12:55:58 server systemd[1]: srv-vdr-video.mount: Mount process exited, code=exited, status=32/n/a

    Feb 14 12:55:58 server systemd[1]: srv-vdr-video.mount: Failed with result 'exit-code'.

    Feb 14 12:55:58 server systemd[1]: Failed to mount /srv/vdr/video.


    Wie gesagt: Netzwerk ist halt noch nicht da :-/

  • Wie gesagt: Netzwerk ist halt noch nicht da :-/

    Aber Deine Meldung sagen IMHO eigentlich was anderes ... schräg ...

    Feb 14 09:53:51 server systemd[1]: Reached target Network is Online.

    HowTo: APT pinning

  • Aber Deine Meldung sagen IMHO eigentlich was anderes ... schräg ...

    Genau da liegt für mich der Hund begraben, aber wie ändern? Das Target ist halt doch noch nicht "reached". Nervig...


    Habe auch schon mal Netplan auf DHCP umgestellt, macht aber keine Unterschied. Ich hatte die Hoffnung, daß er dann auf die IP wartet, somit Link schon da sein muß -> negativ.

  • Hier noch mal die deps vom network-online.target


    root@server:~# systemctl list-dependencies network-online.target

    network-online.target

    ● ├─NetworkManager-wait-online.service

    ● └─systemd-networkd-wait-online.service

  • Ich hatte die Hoffnung, daß er dann auf die IP wartet, somit Link schon da sein muß -> negativ.

    Wie meinst Du das?


    Sieht doch eher nach einen Netzwerk Problemchen aus, denn eines mit NFS ...


    Schonmal probiert auf die (gute) alte "ethX" Interface Mimik umzuschalten, in /etc/default/grub z.B. GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"


    Sonstige Leichen in /etc/network ... ?


    Der Vorteil einer custom systemd Mount Unit ist, das man die Abhängigkeit zum VDR herstellen kann. Der klassische Eintrag in /etc/fstab, der am Ende zwar auch in einer virtuellen Mount Unit mündet hat diese nicht ...

    HowTo: APT pinning

  • Es muß irgendwo in den Tiefen von systemd "verbogen" gewesen sein.

    Nach beherzter Neuinstallation mounten NFS-Shares aus der fstab wieder "wie gewohnt" (auch ohne besondere Optionen), lediglich den vdr.service musste ich nach /etc/systemd/system klonen, und statt


    After=network.target wartet er nun auf After=srv-vdr-video.mount (die automatisch generierte unit aus der fstab).

    Zusammengefasst: Problem war, das network-online.target schon erreicht war, wenn network-online noch nicht gegeben war (warumauchimmer)

    Ich habe den Weg gewählt, VDR auf den automatischen Mountpoint warten zu lassen, weil ich noch mehrere nfs-mounts benötige, die Lösung dieser Thematik also vorrangig war.

    Danke allen Mitstreitern!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!