mount.nfs: Stale NFS file handle [Résolu]

[SYL666]

Bonjour,

Pour une raison inconnu, mon partage NFS boude depuis ce matin. Je crois que la seule chose que j'ai faite a été de mettre une option erronée dans /etc/exports, puis de la retirer.

Depuis, quand j'essaie de monter mon partage depuis une autre machine, j'ai l'erreur suivante :
mount.nfs: Stale NFS file handle

Et ce sur chacun de mes clients

Le mode verbose est pas très intéressant.

Si j'essaie de monté localement le partage, ça coince (d'après strace, le mount reste coincé sur un wait4(-1, [...])).
Ce qui est d'ailleurs étrange, car le premier argument de wait4 est sensé être un PID.

En regardant ici et la sur des forums, j'ai essayé les solutions suivantes :
* arrêt des firewalls
* reboote de chacune des machines
* fsck du file system (ext4)
* rmdir / mkdir du répertoire de destination

J'ai l'impression que des fichiers ont été mal fermé quelque part, et qu'il y a un manque de synchro. Mais comme les reboots n'y font rien... je ne sais pas

[EDIT]
J'ai essayé en supprimant des lignes de /var/lib/nfs/rmtab... ça ne change pas
J'ai essayé en mettant du debug mais il n'y a rien d'intéressant

[jmelyn]

Bonjour,

Il peut y avoir plusieurs raisons pour que le serveur ne réponde pas. Mais les indices sont peu nombreux. Que dit le log système (en général /var/log/messages) du serveur lorsque le montage du client échoue?

Lorsque tu as changé les paramètres du service NFS, as-tu redémarré le service, genre service nfs restart?

Il se peut aussi que le pare-feu empêche toute connexion du client. Pour vérifier, une commande du genre service iptables status te donne les règles appliquées pour bloquer ou transmettre les requêtes réseau.

Si tout est correct ici, donne la distribution du serveur, c'est toujours mieux.

Bonne chance.

Edit: Pas bien lu ton post jusqu'au bout. Donc il semble que le pare-feu et le redémarrage du service nfs ne soient pas en cause. Le mieux est que tu nous montres le fichier /etc/exports, et ce que dit un montage manuel.

[SYL666]

Nada, y a que dalle dans les messages...

Voila ce qu'il se passe dans les logs (j'ai mis du debug, et j'ai marqueur avec logger pour etre sur de ne rien manquer) :
----8<----
mountd[1499]: MNT3(/exports) called
mountd[1499]: authenticated mount request from node3:721 for /exports (/)
---->8----

Entre temps, j'ai créer un 2nd partage NFS, qui lui fonctionne très bien, sans soucis.

Je suis passer par tcpdump pour essayer d'avoir un peu plus d'info :
Le serveur retourne une erreur NFS3ERR_STALE (70)

Défini comme :

NFS3ERR_STALE
Invalid file handle. The file handle given in the
arguments was invalid. The file referred to by that file
handle no longer exists or access to it has been
revoked.

Donc je suis assez persuadé qu'un truc dans le cache du client s'est mal déroulé, et qu'il essaie d'utiliser un mauvais File Handle pour la connexion.
J'ai même essayé de grepper le file handle en question dans /proc et /var/lib/nfs, mais j'ai rien trouvé.

D'un autre coté, TOUS mes clients sont impactés... donc c'est plutôt coté serveur que cela se passe.

Entre temps, pour le moment, je passe par mon nouveau partage... Mais je ne comprends pas et c'est con, je deviens fou...

[SYL666]

Nada, y a que dalle dans les messages...

Voila ce qu'il se passe dans les logs (j'ai mis du debug, et j'ai marqueur avec logger pour etre sur de ne rien manquer) :
----8<----
mountd[1499]: MNT3(/exports) called
mountd[1499]: authenticated mount request from node3:721 for /exports (/)
---->8----

Entre temps, j'ai créer un 2nd partage NFS, qui lui fonctionne très bien, sans soucis.

Je suis passer par tcpdump pour essayer d'avoir un peu plus d'info :
Le serveur retourne une erreur NFS3ERR_STALE (70)

Défini comme :

NFS3ERR_STALE
Invalid file handle. The file handle given in the
arguments was invalid. The file referred to by that file
handle no longer exists or access to it has been
revoked.

Donc je suis assez persuadé qu'un truc dans le cache du client, ou du serveur, s'est mal déroulé, et qu'il essaie d'utiliser un mauvais File Handle pour la connexion.
J'ai même essayé de grepper le file handle en question dans /proc/fs et /var/lib/nfs, mais j'ai rien trouvé.

D'un autre coté, TOUS mes clients sont impactés... donc c'est plutôt coté serveur que cela se passe.

Entre temps, pour le moment, je passe par mon nouveau partage... Mais je ne comprends pas et c'est con, je deviens fou...

[SYL666]

désolé pour le double post... En plus de tout ça, Internet fait des caprices

Mon /etc/exports :
/exports 192.168.122.*(rw)
/exports2 *(rw)

exports2 fonctionne très bien...


Et je viens de trouver ce qui coince : 192.168.122.* : j'ai le même comportement sur exports2 si je la mets en place. Et exports se remet à fonctionner correctement si je l'enlève.

Cette option est correcte, la plage d'adresses est bonne, cela a marché correctement pendant plusieurs semaines sans soucis.


bug ?

[jmelyn]

La man page d'exports (anglais, désolé) dit que:

Wildcard characters generally do not work on IP addresses, though they may work by accident when reverse DNS lookups fail.

Autrement dit, pas de méta-caractère sur les adresses IP, même si ça peut marcher par accident.

À la place, il faut utiliser la notation CIDR ou le netmask:

• CIDR: 192.168.122.0/24, qui veut dire que les vingt-quatre bits de poids fort sont fixés. Il reste donc les huit bits de poids faible libres.
• Le netmask: 192.168.122.0/255.255.255.0 veut dire la même chose.

J'espère que j'ai été clair.

[SYL666]

Bien vu

Effectivement, j'ai eu de la chance pendant 1 bon mois alors

j'ai changé mon /etc/hosts et mon hostname sur mon serveur quelques jours plus tôt, ça doit venir de la... le truc qui faisait que j'étais chanceux à disparu, et pouff.... ça fait des chocapic!

[Modif]
Merci à vous toi seul!!

[jmelyn]

Addendum:

Chez nous, nous créons un fichier /etc/netgroup qui contient tous les clients, nominativement, nous en faisons des groupes (et même des groupes de groupes!), et nous utilisons le nom de ces groupes dans l'exports. Nous pouvons faire ainsi un fichier exports lisible parce que nous avons des dizaines d'exports pour des milliers de machines réparties en groupes. Par exemple:

Code :

/data @dev(rw,async,insecure) @adm(rw,async,insecure,no_root_squash)

Ici le file-system /data est exporté aux machines du groupe dev en Read-Write et aux machines du groupe adm en Read-Write avec en plus root qui reste root.

[SYL666]

Oui, effectivement, j'ai entendu parler des netgroup.
Mais c'est trop avancé pour ce que je souhaite faire pour le moment.