NFS-Volume kann nicht gemountet werden - Timeout

Ich habe einen NFSv3-Export von einem Linux-Dateiserver, der früher einwandfrei gemountet hat. Der Dateiserver musste für die Hardwarewartung ausfallen. Nach dem Sichern des Servers kann der Linux-Client den NFS-Export nicht mehr bereitstellen.

Auf dem Server oder dem Client hat sich keine Konfiguration geändert. Ich habe ein Software-Update durchgeführt und den Client neu gestartet, nachdem der erste Mount fehlgeschlagen war, aber das hat nicht geholfen.

[root@client ~]# showmount -e ark
Export list for ark:
/mnt/bigraid *

[root@client ~]# mount -t nfs ark:/mnt/bigraid raid

Es hängt nur an dieser Stelle. In einem anderen Terminal ...

[root@client ~]# dmesg | tail
[ 2526.676437] nfs: server ark not responding, timed out
[ 2529.183107] nfs: server ark not responding, timed out
[ 2531.689778] nfs: server ark not responding, timed out
[ 2538.196432] nfs: server ark not responding, timed out
[ 2540.703107] nfs: server ark not responding, timed out
[ 2543.209767] nfs: server ark not responding, timed out
[ 2545.716436] nfs: server ark not responding, timed out
[ 2548.223098] nfs: server ark not responding, timed out
[ 2550.729775] nfs: server ark not responding, timed out
[ 2557.236435] nfs: server ark not responding, timed out

... OK, aber ich konnte die Exporte mit showmount sehen ...

[root@client ~]# ping ark
PING ark.homebase (10.10.10.2) 56(84) bytes of data.
64 bytes from ark.homebase (10.10.10.2): icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=4 ttl=64 time=0.042 ms
^C
--- ark.homebase ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms

Also verstehe ich es nicht.

Auf dem Server wird OpenSUSE ausgeführt. Ich habe sichergestellt, dass die Firewall ausgeschaltet war (nicht, dass sie jemals eingeschaltet war) und dass die Netzwerkkonnektivität in Ordnung zu sein scheint.

ark:/etc # cat exports
/mnt/bigraid    *(rw,root_squash,insecure,no_subtree_check,sync)

Bearbeiten: Hier ist die Liste der verwendeten RPC-Ports

ark:/etc/init.d # rpcinfo -p
program vers proto   port
100000    2   tcp    111  portmapper
100005    1   udp  37599  mountd
100005    1   tcp  33880  mountd
100005    2   udp  37599  mountd
100005    2   tcp  33880  mountd
100005    3   udp  37599  mountd
100005    3   tcp  33880  mountd
100024    1   udp  49522  status
100024    1   tcp  41314  status
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100021    1   udp  51887  nlockmgr
100021    3   udp  51887  nlockmgr
100021    4   udp  51887  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100021    1   tcp  49804  nlockmgr
100021    3   tcp  49804  nlockmgr
100021    4   tcp  49804  nlockmgr
100000    2   udp    111  portmapper

Edit 2: Habe einige tcpdump Informationen

(Edit 3: tcpdump-Ausgabe entfernt, da sie möglicherweise nicht relevant ist.)

Ich bin überhaupt nicht vertraut damit, wie eine richtige NFS-Verhandlung aussieht. Ich habe auch eine pcap-Datei ausgegeben, wenn Sie sich die Datensegmente ansehen möchten. Es ist bei Filedropper

Bearbeiten 3: Ich kann dieses Problem treffen

Ich habe den Rat von @ CIA unten befolgt und dies getan:

ark:/etc/init.d #  ./nfsserver stop
Shutting down kernel based NFS server: nfsd statd mountd idmapd       done
ark:/etc/init.d # ./portmap stop
Shutting down RPC portmap daemon                                      done
ark:/etc/init.d # ./portmap start
Starting RPC portmap daemon                                           done
ark:/etc/init.d # ./nfsserver start
Starting kernel based NFS server: idmapdexportfs: Warning: /mnt/bigraid does not support NFS export.
 mountd statd nfsd sm-notify                                          done

Trotz der Warnung scheint der Export nun montierbar zu sein.

NFS ist insofern seltsam, als es darauf basiert, dass Portmapper ausgeführt wird, sodass es einen bestimmten Port einem RPC-Port zuordnen kann. (Ich denke, es ist nicht seltsam. Es funktioniert einfach so.) Wenn NFS vor Portmapper aktiv ist, weiß NFS nicht, wie Anforderungen weitergeleitet werden sollen, da Portmapper zu Beginn des Prozesses darauf überprüft wird. Wenn Portmapper vor NFS nicht aktiv ist, weiß NFS nicht, wie der Port dem RPC zugeordnet werden soll.

Hier finden Sie weitere Dokumentationen zu diesem Prozess (auch wenn er für CentOS relevant ist): http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s2-nfs-methodology-portmap.html

Starten Sie Ihre neue Fehlermeldung neu, und starten Sie sie erneut, um festzustellen, ob der Fehler erneut auftritt.

tcpdump -i $LAN_IF -n host 10.10.10.2

sollte Ihnen zeigen, welche der NFS-Komponenten ausfällt.

Nun, ich habe immer den gleichen Fehler bekommen. Ich habe festgestellt, dass der einzige Grund für eine Zeitüberschreitung darin besteht, dass die Verbindung nicht ordnungsgemäß hergestellt wurde. Als ich mich eingehender mit dem Problem befasste, überprüfte ich meine Firewall und der verdammte NFS4-Dienst wurde blockiert !!

Lösung: - Verwenden Sie den folgenden Befehl, um Ihre Firewall-Einstellungen zu konfigurieren, und fügen Sie * neben dem NFS4-Dienst hinzu, um ihn zu aktivieren.

$ sudo system-config-firewall-tui

Um die Lösung aus den gegebenen Antworten zusammenzufassen, leite ich diese Schritte in die richtige Richtung, um NFS zu reparieren, damit es erfolgreich gemountet werden kann, ohne die Box neu zu definieren .

1. Führen Sie einen tcpdump auf dem Client-Server unter der IP-Adresse des NFS-Servers aus (vorausgesetzt, es ist 1.2.3.4).

   tcpdump -i <replace-with-correct-INTERFACE_name -n host 1.2.3.4
   

2. Führen Sie tcpdump weiter aus und versuchen Sie, den NFS-Pfad bereitzustellen.

3. Nachschlagen der Ports Der NFS-Server kommuniziert mit dem Client, um den Pfad bereitzustellen (in Ihrem Fall [tcpdump führt zu einer Bearbeitungsrevision] sind dies nur die Ports: 880, 2049).

4. Führen Sie Telnet für die NFS-Server-IP und alle Ports aus, die Sie in Schritt 3 aus der tcpdump-Ausgabe erhalten haben, und stellen Sie sicher, dass an allen Ports Telnet vorhanden ist (in Ihrem Fall nur 2 unter den Ports).

   telnet 1.2.3.4 880
   telnet 1.2.3.4 2049
   

5. Wenn an keinem der in Schritt 3 erfassten Ports Telnet vorhanden ist, müssen Sie diese Ports auf Netwrok-Ebene (und gegebenenfalls an der Firewall) öffnen.

6. Versuchen Sie jetzt erneut, das NFS zu mounten.

Aktivieren Sie die folgenden TCP- und UDP-Ports, damit Clients auf die NFS-Freigabe auf dem Server zugreifen können.

Für NFS3 tcp: 111,662,875,892,2020,2049,32803
udp: 111,2049,32769

Für NFS4

tcp: 111,2049 udp: 111,2049

Bearbeiten: Versuchen Sie, die oben genannten Ports vom NFS-Client aus zu telneten

Wenn Sie eine hostbasierte Firewall haben und nfs verwenden, lesen Sie Folgendes:

http://wiki.debian.org/SecuringNFS

Möglicherweise haben Sie angegeben, welche Ports Ihre Daemons verwenden, damit sie nicht zufällig zugewiesen werden.

In meinem Fall bestand das Problem darin, dass der Server neu nummeriert wurde, der Client jedoch weiterhin versuchte, eine Verbindung zur alten IP-Adresse herzustellen.

Dies hat dazu beigetragen, das Problem auf dem NFS-Client-Host zu identifizieren:

mount | grep addr=