Montaggio NFS non riuscito, autorizzazione negata, nessuna voce di esportazione

Ho un problema con il montaggio di una condivisione NFS che non riesco a risolvere che mi sta facendo impazzire. Questa è la situazione:

Tre macchine coinvolte:
Host A: mandragola, IP 192.168.1.4, server NFS
Host B :ockeyon64, IP 192.168.1.64, client NFS
Host C: lap-fzs-2, IP 192.168.1.27, client NFS

L'host A ha un server NFS in esecuzione che esporta una directory che viene montata dall'host B. Funziona perfettamente e funziona da secoli. Nessun problema. Ora l'host C entra in scena. Ubuntu 12.04 LTS, sistema moderno. Ho provato a montare la stessa condivisione dall'host A ma ho ricevuto un errore di autorizzazione negata:

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

Il fatto che funzioni tra gli host A e B dovrebbe dimostrare che l'esportazione NFS in sé funziona. Ecco le informazioni che posso dare che mi fanno pensare che dovrebbe funzionare. Forse qualcuno vede quello che io non so e sa perché questo fallisce sul nuovo host C.

Esportazioni di server:

[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

Il portmapper è in esecuzione, le esportazioni sono note e montate dall'host B "ornamon64".

[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

Quando l'hostockeyon64 monta la condivisione NFS, il registro del server mostra successo:

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

Ma quando l'host C tenta di montare la stessa condivisione, il registro del server mostra:

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

L'host C vede il server, raggiunge il portmapper e l'nfsd, ma fallisce con le autorizzazioni.

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

Devo usare NFSv2 sul client. L'uso di NFSv4 fallirà poiché il server non lo supporta. Non riesce poiché tenta di connettersi tramite TCP direttamente al 2049 ma la porta non è aperta. Non si verifica alcun fallback. L'uso di NFSv3 comporterà una mancata corrispondenza del programma / versione RPC.

Cosa mi sto perdendo?

Aggiornamento:
tutte e tre le macchine sono su una LAN, sullo stesso switch. Nessun firewall attivo sull'host 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

Né sull'host A:

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

linux nfs

— Florian
fonte

Firewall su Host C (o meno probabile Host A)? (Cosa mostra / sbin / iptables -vnL?)

— davidgo,

No, nessun firewall, un segmento LAN.

— Florian,

prova il exportfs -acomando sull'host A, quindi prova il mountcomando sull'host C. Prova il nome host esplicito o l'indirizzo IP completo in /etc/exports.

— segatura,

Come sarebbe d'aiuto? Il server esegue un'operazione exportfs -aall'avvio e poiché questa non è una nuova voce, è già esportata. Il file delle esportazioni non è cambiato, è solo un nuovo host che dovrebbe montarlo e non può.

— Florian,

@sawdust la tua modifica conteneva il giusto suggerimento: l'uso dell'indirizzo IP completo in /etc/exportsrealtà lo fa funzionare. Ora ho la / 24 net più l'IP completo elencato e l'host C può montare. Non ho ancora provato l'host B. Qualche idea sul perché questo sia? Ho notato che l'host B (quello funzionante) ha usato una chiamata MNT versione 2, mentre l'host C ha fatto ricorso a una chiamata MNT versione 1.

— Florian,

11 febbraio 20:12:42 mandrake mountd [460]: richiesta di montaggio rifiutata da lap-fzs-2 per / data (/): nessuna voce di esportazione

Poiché l'avviso di rifiuto del server afferma che non esiste "nessuna voce di esportazione" per l'host C, allora forse dovresti provare una riga non ambigua nel /etc/exportsfile con il nome host esplicito o l'indirizzo IP completo per C.

Prova anche a inviare un exportfs -acomando sul server.
Ho spesso problemi ad accedere al mio server NFS anche dopo il riavvio. Emettere esplicitamente il exportfs -acomando è la soluzione affidabile (per me).

— segatura
fonte

L'esplicito, ripetuto exportfs -anon ha cambiato nulla per me. L'uso dell'indirizzo IP completo per un host problematico ha risolto il mio problema. Quindi, anche se questo non lo spiega e non lo capisco, è stata la risposta al mio problema e ciò che posso consigliare di provare per gli altri con lo stesso problema.

— Florian,

L'aggiunta di una voce per l'indirizzo IP problematico in / etc / exports ha risolto anche il mio problema. Strano.

— PLA,

Controlla se UID e GUID per gli utenti NFS sono gli stessi su server e client. Inoltre, assicurati che sul server la cartella abbia l'autorizzazione 777. Questa è la mia / etc / exports sul mio server per l'accesso al mio client.

Creare una directory di condivisione NFS: (Creare ciascun server con IP, spazio separato)

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
fonte

UID e GID non sono gli stessi. Non devono esserlo, funziona una volta montata la condivisione sul client NFS. E per l'operazione di mount gli UID dell'utente dovrebbero essere irrilevanti. Dubito che l'impostazione della cartella su 777 sia una buona idea, soprattutto se gli utenti possono accedere al server. Ancora una volta, ha funzionato senza che una volta che l'ho montato.

— Florian,

Nel mio caso, -o vers = 3 è la risposta:

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

Server NFS: Ubuntu desktop 12.04 host vmware a 32 bit
Client NFS: server Ubuntu 12.04 64-bit guest vmware (modalità solo host)

— Fumisky Wells
fonte