Le montage NFS échoue, autorisation refusée, aucune entrée d'exportation

J'ai un problème de montage d'un partage NFS que je ne peux pas résoudre et qui me rend fou. Voici la situation:

Trois machines impliquées:
Hôte A: mandrake, IP 192.168.1.4, serveur NFS
Hôte B: athlon64, IP 192.168.1.64, client NFS
Hôte C: lap-fzs-2, IP 192.168.1.27, client NFS

L'hôte A possède un serveur NFS en cours d'exécution qui exporte un répertoire qui est monté par l'hôte B. Cela fonctionne parfaitement et fonctionne depuis des siècles. Pas de problème. Maintenant, l'hôte C entre en scène. Ubuntu 12.04 LTS, système moderne. J'ai essayé de monter le même partage à partir de l'hôte A mais j'obtiens une erreur de refus d'autorisation:

root@lap-fzs-2:~# mount -t nfs mandrake:/data /data -onfsvers=2
mount.nfs: access denied by server while mounting mandrake:/data

Le fait qu'il fonctionne entre les hôtes A et B devrait prouver que l'exportation NFS fonctionne en soi. Voici les informations que je peux donner qui me font penser que cela devrait fonctionner. Peut-être que quelqu'un voit ce que je ne sais pas et sait pourquoi cela échoue sur le nouvel hôte C.

Exportations de serveur:

[root@mandrake /root]# cat /etc/exports
/suse 192.168.1.0/16(ro,no_root_squash)
/data 192.168.1.0/24(rw)
#/data3 192.168.2.0/24(rw)
#/data 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)
#/data3 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)

[root@mandrake /root]# exportfs
/suse           192.168.1.0/16
/data           192.168.1.0/24

Le portmapper est en cours d'exécution, les exportations sont connues et montées par l'hôte B "athlon64".

[root@mandrake /root]# showmount -e
Export list for mandrake:
/data 192.168.1.0/24
/suse 192.168.1.0/16
[root@mandrake /root]# showmount -a
All mount points on mandrake:
atlhon64.acme.local:/data

Lorsque l'hôte athlon64 monte le partage NFS, le journal du serveur affiche le succès:

Feb 11 20:06:46 mandrake mountd[460]: authenticated mount request from atlhon64.acme.local:770 for /data (/data)

Mais lorsque l'hôte C tente de monter le même partage, le journal du serveur affiche:

Feb 11 20:12:42 mandrake mountd[460]: refused mount request from lap-fzs-2 for /data (/): no export entry

L'hôte C voit le serveur, atteint le portmapper et le nfsd, mais échoue aux autorisations.

root@lap-fzs-2:~# showmount -e 192.168.1.4
Export list for 192.168.1.4:
/data 192.168.1.0/24
/suse 192.168.1.0/16


root@lap-fzs-2:~# mount -t nfs -v mandrake:/data /data -onfsvers=2,proto=udp
mount.nfs: timeout set for Mon Feb 11 21:49:23 2013
mount.nfs: trying text-based options 'nfsvers=2,proto=udp,addr=192.168.1.4'
mount.nfs: prog 100003, trying vers=2, prot=17
mount.nfs: trying 192.168.1.4 prog 100003 vers 2 prot UDP port 2049
mount.nfs: prog 100005, trying vers=1, prot=17
mount.nfs: trying 192.168.1.4 prog 100005 vers 1 prot UDP port 636
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting mandrake:/data

Je dois utiliser NFSv2 sur le client. L'utilisation de NFSv4 échouera car le serveur ne le prend pas en charge. Il échoue car il essaie de se connecter via TCP directement à 2049 mais le port n'est pas ouvert. Aucune solution de repli ne se produit. L'utilisation de NFSv3 entraînera une incompatibilité de programme / version RPC.

Qu'est-ce que je rate?

Mise à jour:
Les trois machines sont sur un LAN, sur le même commutateur. Il n'y a pas de pare-feu actif sur l'hôte C:

root@lap-fzs-2:~# iptables -vnL
Chain INPUT (policy ACCEPT 17 packets, 1853 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 20 packets, 5611 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ni sur l'hôte A:

[root@mandrake /root]# ipchains -L 
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

linux nfs

— Florian
source

Pare-feu sur l'hôte C (ou moins probablement l'hôte A)? (Que montre / sbin / iptables -vnL?)

— davidgo

Non, pas de pare-feu, un segment LAN.

— Florian

essayez la exportfs -acommande sur l'hôte A, puis essayez la mountcommande sur l'hôte C. Essayez le nom d'hôte explicite ou l'adresse IP complète dans /etc/exports.

— sciure

Comment cela aiderait-il? Le serveur fait un exportfs -aau démarrage et comme il ne s'agit pas d'une nouvelle entrée, il est déjà exporté. Le fichier d'export n'a pas changé, c'est juste un nouvel hôte qui devrait le monter et ne peut pas.

— Florian

@sawdust votre modification contenait le bon indice: l'utilisation de l'adresse IP complète en /etc/exportsfait, cela fonctionne. J'ai maintenant le net / 24 plus l'IP complet répertorié et l'hôte C peut être monté. Je n'ai pas encore essayé l'hôte B. Une idée pourquoi c'est? J'ai remarqué que l'hôte B (celui qui fonctionnait) utilisait un appel MNT version 2, tandis que l'hôte C avait recours à un appel MNT version 1.

— Florian

11 février 20:12:42 mandrake mountd [460]: demande de montage refusée de lap-fzs-2 pour / data (/): aucune entrée d'exportation

Étant donné que l'avis de rejet du serveur prétend qu'il n'y a "aucune entrée d'exportation" pour l'hôte C, vous devriez peut-être essayer une ligne sans ambiguïté dans le /etc/exportsfichier avec le nom d'hôte explicite ou l'adresse IP complète pour C.

Essayez également d'émettre une exportfs -acommande sur le serveur.
J'ai souvent des problèmes pour accéder à mon serveur NFS même après un redémarrage. Émettre explicitement la exportfs -acommande est la solution fiable (pour moi).

— sciure
source

L'explicite, répété exportfs -an'a rien changé pour moi. L'utilisation de l'adresse IP complète pour l'hôte problématique a résolu mon problème. Donc, même si cela ne l'explique pas et que je ne le comprends pas, c'était la réponse à mon problème et ce que je peux recommander d'essayer pour d'autres personnes ayant le même problème.

— Florian

L'ajout d'une entrée pour l'adresse IP problématique dans / etc / exports a également résolu mon problème. Bizarre.

— PLA

Vérifiez et voyez si l'UID et le GUID pour les utilisateurs NFS sont les mêmes sur le serveur et le client. Assurez-vous également que sur le serveur le dossier est autorisé 777. Il s'agit de mon / etc / exports sur mon serveur pour que mon client puisse y accéder.

Créez un répertoire de partage NFS: (Créez chaque serveur avec IP, espace séparé)

mkdir / var / nfs vim / etc / exports / var / nfs 10.180.82.250 (rw, sync, root_squash, anonuid = 530, anongid = 530, no_subtree_check)

— Tony-Caffe
source

L'UID et le GID ne sont pas identiques. Ils ne doivent pas l'être, cela fonctionne une fois que le partage est monté sur le client NFS. Et pour l'opération de montage, les UID de l'utilisateur ne devraient pas être pertinents. Je doute que la définition du dossier sur 777 soit une bonne idée, surtout si les utilisateurs peuvent se connecter au serveur. Encore une fois, cela a fonctionné sans cela une fois que je l'ai monté.

— Florian

Dans mon cas, -o vers = 3 est la réponse:

$ sudo mount -o vers=3 192.168.172.1:/A/DIR /mnt

Serveur NFS: hôte vmware Ubuntu desktop 12.04 32 bits
Client NFS: serveur Ubuntu 12.04 invité vmware 64 bits (mode hôte uniquement)

— Fumisky Wells
source