[gelöst][yavdr ansible, bionic] NFS mount

minixjr · 1. Februar 2020

Hallo zusammen,

habe grade das Problem, dass ich von keinem meiner Clients ein NFS Share mounten kann

Kann das Jemand bestätigen, oder bin ich alleine?

journalctl -b | grep -E "NFS|nfs"

Code

Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,658 INFO   skip local service 'Recordings on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,658 INFO   skip local service 'Pictures on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,658 INFO   skip local service 'Files on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,659 INFO   skip local service 'Backups on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,659 INFO   skip local service 'Audio on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,659 INFO   skip local service 'Video on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,660 INFO   skip local service 'Video on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,660 INFO   skip local service 'Recordings on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,660 INFO   skip local service 'Pictures on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,661 INFO   skip local service 'Files on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,661 INFO   skip local service 'Backups on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:55:47 vdrserver avahi-linker[26631]: 2020-02-01 18:55:47,662 INFO   skip local service 'Audio on vdrserver' type '_nfs._tcp' domain 'local'
Feb 01 18:57:40 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:00:53 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:04:05 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:04:05 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:07:18 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:10:30 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:13:43 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:16:55 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out
Feb 01 19:20:08 vdrserver kernel: nfs: server 192.168.64.166 not responding, timed out

Alles anzeigen

An meinem QNAP scheint es nicht zu liegen, mit Debian Sid (Siduction) kann ich meine NFS Freigaben mounten.

Gruß

Frank

minixjr · 2. Februar 2020

So wie es aussieht, werden die Links per avahi-linker angelegt, aber Zugriff auf die Dateien habe ich nicht.

Code

root@vdrslz:~# ls -lha /srv/vdr/video/
insgesamt 12K
drwxrwxr-x 1 vdr  vdr  226 Feb  2 16:45  .
drwxrwxrwx 1 vdr  vdr   10 Apr  7  2019  ..
lrwxrwxrwx 1 root root  45 Feb  2 16:26 'Aufnahmen_auf_nase64f00(nfs)' -> '/media/vdr/Aufnahmen auf nase64f00 for vdrslz'
drwxr-xr-x 1 vdr  vdr   88 Jan 31 05:44  Dokumentationen
lrwxrwxrwx 1 root root  45 Feb  2 16:26 'Recordings_on_vdrserver(nfs)' -> '/media/vdr/Recordings on vdrserver for vdrslz'
lrwxrwxrwx 1 root root  46 Feb  2 16:26 'Recordings_on_yavdrbox-2(nfs)' -> '/media/vdr/Recordings on yavdrbox-2 for vdrslz'
drwxr-xr-x 1 vdr  vdr   28 Feb  1 08:43  Serien
-rw-r--r-- 1 vdr  vdr    0 Feb  2 16:19  .update
root@vdrslz:~# ls -lha '/media/vdr/Aufnahmen auf nase64f00 for vdrslz'
lrwxrwxrwx 1 root root 18 Feb  2 16:26 '/media/vdr/Aufnahmen auf nase64f00 for vdrslz' -> /net/nase64f00/VDR
root@vdrslz:~# ls -lha /net/nase64f00/VDR/
ls: Zugriff auf '/net/nase64f00/VDR/' nicht möglich: Datei oder Verzeichnis nicht gefunden

Alles anzeigen

Das letzte Update habe ich versucht rückgängig zu machen und die alten Pakete für bionic heruntergeladen und installiert, leider ohne Erfolg.

Mangels für mich sichtbarer Fehlermeldungen, bin ich völlig ratlos

Info: nase64f00 ist mein QNAP, vdrserver und yavdrbox sind ansible bionic Installationen.

Niemand eine Idee was ich versuchen könnte?

seahawk1986 · 2. Februar 2020

Kannst du denn die NFS-Freigaben händisch mounten?

minixjr · 2. Februar 2020

Nein, wenn ich es versuche passiert nix, sieht nach einem Timeout aus.

Code

sudo mount -v -t nfs vdrserver:/srv/vdr/video /mnt
mount.nfs: timeout set for Sun Feb  2 19:31:47 2020
mount.nfs: trying text-based options 'vers=4.2,addr=2003:e0:cf2c:e300:3f77:3212:1f0d:366,clientaddr=2003:e0:cf2c:e300:962:8c20:990a:2107'
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=4.2,addr=fd00:3a10:d5ff:feb6:ff37:c496:362d:43c1,clientaddr=fd00:3a10:d5ff:feb6:e5:81ea:8716:4c70'

Mit Optionen wie "tcp", also nur ipv4, keine Änderung.

Von meinem Debian-Client kann ich nur das NAS mounten, bei den yavdr Freigaben passiert auch nix, wie oben.

seahawk1986 · 3. Februar 2020

Löst dein Debian die Hostnamen auch als IPv6-Adressen auf? Unterstützt dein NAS NFS über IPv6? Klappt ein Mount, wenn du die IPv4-Addresse des NAS angibst?

minixjr · 3. Februar 2020

Mounten über IPv4 funktioniert nicht, hatte ich schon probiert. Den Rest kann ich erst testen/nachsehen wenn ich wieder Zuhause bin, ab Mittwoch.

Das Mounten der yavdr-Rechner untereinander funktioniert auch nicht. Anpingen über den Rechnernamen funktioniert bei allen.

minixjr · 5. Februar 2020

Zitat

Löst dein Debian die Hostnamen auch als IPv6-Adressen auf?

Ja und nein --> ping HOSTNAME
yavdr-ansible-Clients löst es IPv6 auf (bei -4 dann auch als IPv4), das NAS IPv4.

Die yavdr-ansible-Clients untereinander als IPv6 (bei -4 dann auch als IPv4), das NAS als IPv4

Zitat

Unterstützt dein NAS NFS über IPv6?

Scheinbar nicht, obwohl es eigentlich IPv6 können müsste. Aber nicht mal das anpingen funktioniert (von keinem Rechner)

Code

ping -6 nas
ping: nas: Der Name oder der Dienst ist nicht bekannt

Zitat

Klappt ein Mount, wenn du die IPv4-Addresse des NAS angibst?

Debian Client, nach dem Befehl ist das Share sofort verbunden:

Code

sudo mount -v -t nfs -o tcp 192.168.64.168:/VDR /mnt
mount.nfs: timeout set for Wed Feb  5 14:31:00 2020
mount.nfs: trying text-based options 'tcp,vers=4.2,addr=192.168.64.168,clientaddr=192.168.64.173'

yavdr-ansible-Clients, nach dem Befehl kommt nach ca. 5 Minuten ein Timeout:

Code

sudo mount -v -t nfs -o tcp 192.168.64.168:/VDR /mnt
mount.nfs: timeout set for Wed Feb  5 14:33:04 2020
mount.nfs: trying text-based options 'tcp,vers=4.2,addr=192.168.64.168,clientaddr=192.168.64.191'
mount.nfs: mount(2): Connection timed out
mount.nfs: Connection timed out

Nach dem das Problem bei mir aufgetreten ist, gab es jetzt von Ubuntu noch Updates zu mount und libmount, hat aber am Verhalten nichts geändert.

Das hier LINK sieht nach meinem Problem aus, leider ohne Lösung. Ich werde aber mal die Kabel prüfen/tauschen.

seahawk1986 · 5. Februar 2020

Was sagt denn ip addr auf einem der yaVDR-Rechner?

Hast du mal als Würgaround versucht den IPv6-Stack des Kernels komplett zu deaktivieren (https://www.purrucker.de/2018/…8-04-server-deaktivieren/ - da muss man ggf. bei einigen Diensten aufpassen, wenn die dafür konfiguriert sind über localhost IPv6 Verbindungen zu gehen)?

minixjr · 6. Februar 2020

ip addr eines yaVDR-Rechners

Code

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 10:c3:7b:50:5e:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.166/24 brd 192.168.64.255 scope global dynamic enp3s0
       valid_lft 863703sec preferred_lft 863703sec
    inet6 fd00:3a10:d5ff:feb6:12c3:7bff:fe50:5e59/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6903sec preferred_lft 3303sec
    inet6 2003:e0:cf2c:e300:12c3:7bff:fe50:5e59/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6903sec preferred_lft 919sec
    inet6 fe80::12c3:7bff:fe50:5e59/64 scope link 
       valid_lft forever preferred_lft forever

Alles anzeigen

und des Debian-Rechners

Code

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e0:d5:5e:e7:db:79 brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.173/24 brd 192.168.64.255 scope global dynamic noprefixroute enp6s0
       valid_lft 862930sec preferred_lft 862930sec
    inet6 fd00:3a10:d5ff:feb6:e5:81ea:8716:4c70/64 scope global dynamic noprefixroute 
       valid_lft 7029sec preferred_lft 3429sec
    inet6 2003:e0:cf2c:e300:962:8c20:990a:2107/64 scope global dynamic noprefixroute 
       valid_lft 7029sec preferred_lft 1629sec
    inet6 fe80::63e2:fd1f:f99:5180/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 6a:e9:c9:a3:20:61 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

Alles anzeigen

Der Würgaround (schönes Wort ) hat leider nicht geholfen.

Jetzt habe ich nur eine IPv4 aber beim manuellen Mounten kommt immer noch ein Timeout

minixjr · 6. Februar 2020

Ein kleiner Lichtblick, ich habe einen Würgaround mit dem ich wieder per NFS mounten kann.

Nach einem Hinweis von hier LINK, habe ich udp als Mountoption hinzugefügt und damit funktioniert es.

Wenn man die Option auch in /etc/auto.master.d/avahi-linker.autofs einfügt, klappt auch das automatische Mounten wieder.

Interessanterweise wird dann auch nicht NFS4 sondern Version 3 verwendet.

Code

 mount -v -t nfs -o udp vdrserver:/srv/vdr/video /mnt
mount.nfs: timeout set for Thu Feb  6 12:49:26 2020
mount.nfs: trying text-based options 'udp,vers=4.2,addr=192.168.64.191,clientaddr=192.168.64.190'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'udp,vers=4.1,addr=192.168.64.191,clientaddr=192.168.64.190'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'udp,vers=4.0,addr=192.168.64.191,clientaddr=192.168.64.190'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'udp,addr=192.168.64.191'
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: trying 192.168.64.191 prog 100003 vers 3 prot UDP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.64.191 prog 100005 vers 3 prot UDP port 36531

Alles anzeigen

minixjr · 7. Februar 2020

So, habe es endlich gefunden. Der Link im vorherigen Beitrag enthielt die Lösung.

Ich habe einen Switch der auch Securityfeatures hat.

Aus welchen Gründen auch immer war unter "DoS Defend" die Option "SYN sPort less 1024" aktiv, deshalb konnte der Portmapper auf Port 111 nicht angesprochen werden.

Ausgeschlossen hatte ich diesen Fehler weil ja mein Debian-Rechner funktioniert hat, der Grund ist aber scheinbar einfach, Debian und NAS sind direkt an der Fritzbox angeschlossen und nicht am Switch, werden also nicht geblockt

seahawk1986 , besten Dank für Deine Unterstützung und das schöne Wort

[gelöst][yavdr ansible, bionic] NFS mount

Jetzt mitmachen!

Teilen

Tags