Ne peut pas monter le volume NFS - Time Out
J'ai une exportation NFSV3 à partir d'un serveur de fichiers Linux qui utilisait bien. Le serveur de fichiers a dû descendre pour la maintenance matérielle. Après la sauvegarde du serveur, le client Linux ne peut plus monter l'exportation NFS.
Aucune configuration n'a changé sur le serveur ou le client. J'ai fait une mise à jour logicielle et redémarre le client après l'échec du premier montage, mais cela n'a pas aidé.
[root@client ~]# showmount -e ark
Export list for ark:
/mnt/bigraid *
[root@client ~]# mount -t nfs ark:/mnt/bigraid raid
Il se bloque juste à ce stade. Dans un autre 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, mais je pouvais voir les exportations avec showmount ...
[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
Donc je ne comprends pas.
Le serveur est en cours d'exécution opense. Je suis assuré que le pare-feu était éteint (pas que c'était toujours sur) et que la connectivité réseau semble bien.
ark:/etc # cat exports
/mnt/bigraid *(rw,root_squash,insecure,no_subtree_check,sync)
EDIT: Voici la liste des ports RPC utilisés
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: obtenu des informations TCPDump
(Edit 3: Sortie TCPDump supprimée, car elle peut ne pas être pertinente.)
Je ne suis pas du tout familier avec ce qu'une négociation NFS appropriée ressemble. J'ai également vidé d'un fichier PCAP si vous souhaitez examiner les segments de données. C'est à FileDropper
Modifier 3: Je peux frapper ce numéro
Je suivais les conseils de la CIA ci-dessous et j'ai fait ceci:
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
Malgré l'avertissement, l'exportation semble maintenant montable.
Ainsi, NFS est bizarre dans le contenant sur Portmapper pour être en cours d'exécution. Il peut donc cartographier un port spécifique à un port RPC. (Je suppose que ce n'est pas bizarre. C'est comme ça que ça marche.) Si NFS est hausse avant Portmapper, NFS ne sait pas comment suivre les demandes, car elle vérifie Portmapper pour cela au début du processus. Si PortMapper n'est pas à la hauteur avant NFS, NFS ne sait pas comment mapper le port vers RPC.
Voici plus de documentation sur le processus (même si c'est pour Centos, il est toujours pertinent): http://www.centos.org/docs/5/html/deployment_guide-en-us/s2-nfs-methodologie- portmap.html
Quant à votre nouveau message d'erreur, redémarrez la case avec laquelle vous montrez et remontez pour voir si l'erreur revient.
tcpdump -i $LAN_IF -n Host 10.10.10.2
devrait vous montrer lequel des composants NFS échoue.
pour résumer la solution des réponses données, après ces étapes, dirigez-moi vers la bonne direction pour fixer NFS pour l'obtenir monté avec succès sans reformuler la boîte.
exécutez un TCPDump sur le serveur client sur l'adresse IP du serveur NFS (en supposant qu'elle est 1.2.3.4)
tcpdump -i <replace-with-correct-INTERFACE_name -n Host 1.2.3.4continuez à courir TCPDump et essayez de monter le chemin NFS.
- recherchez les ports NFS Server communiquant avec le client pour monter le chemin d'accès (dans votre cas [TCPDump résultat dans Modifier la révision], ce sont des ports: 880, 2049 uniquement).
do Telnet pour NFS Server IP et -tous les ports que vous avez obtenus de la sortie TCPDump à STEP3 et assurez-vous de disposer de TELNET sur tous les ports (votre cas, seulement 2 ports ci-dessous).
telnet 1.2.3.4 880 telnet 1.2.3.4 2049si vous n'avez pas de telnet sur aucun de ces ports capturés à Step3, vous devez ouvrir ces ports au niveau Netwrok (et pare-feu si vous avez)
- essayez de monter la NFS à nouveau maintenant.
Eh bien, j'ai l'habitude d'avoir la même erreur. J'ai réalisé que la seule raison pour y avoir un délai d'attente est que la connexion n'a pas été établie correctement. Creuser plus profondément dans le problème, j'ai vérifié mon pare-feu et le service DAMNN NFS4 a été bloqué !!
SOLUTITIITION: - Utilisez la commande ci-dessous pour configurer vos paramètres de pare-feu et ajouter * à côté du service NFS4 pour l'activer.
$ Sudo system-config-firewall-tui
Si vous avez un pare-feu basé sur l'hôte et utilisez NFS, consultez:
http://wiki.debian.org/securingnfs
Vous pouvez spécifier les ports que vos démons utilisent, de sorte qu'ils ne sont pas assignés au hasard.
Dans mon cas, le problème était que le serveur avait été renuméroté, mais le client essayait toujours de se connecter à l'ancienne adresse IP.
Cela a contribué à identifier le problème sur l'hôte client NFS:
mount | grep addr=
Activez les points suivants TCP et UDP pour les clients d'accéder à NFS Partager sur le serveur.
Pour NFS3 TCP: 111 662 875 892,2020,2049,32803
[.____] UDP: 111,2049,32769
Pour nfs4
tCP: 111,2049 UDP: 111,2049
Edit: Essayez de Telnet les ports ci-dessus du client NFS