Tenho um problema ao montar um compartilhamento NFS que não consigo resolver, o que está me deixando louco. Esta é a situação:
Três máquinas envolvidas:
Host A: mandrake, IP 192.168.1.4, servidor NFS
Host B: Athlon64, IP 192.168.1.64, cliente NFS
Host C: lap-fzs-2, IP 192.168.1.27, cliente NFS
O host A possui um servidor NFS em execução, que exporta um diretório que é montado pelo host B. Isso funciona perfeitamente e funciona há anos. Não há problema. Agora, o host C entra em cena. Ubuntu 12.04 LTS, sistema moderno. Tentei montar o mesmo compartilhamento do host A, mas obtive um erro de permissão negada:
root@lap-fzs-2:~# mount -t nfs mandrake:/data /data -onfsvers=2
mount.nfs: access denied by server while mounting mandrake:/data
O fato de funcionar entre os hosts A e B deve provar que a exportação do NFS por si só está funcionando. Aqui está a informação que posso dar que me faz pensar que deve funcionar. Talvez alguém veja o que não vejo e saiba por que isso falha no novo host C.
Exportações do servidor:
[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
O portmapper está em execução, as exportações são conhecidas e montadas pelo host B "athleton64".
[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 o host Athlonon64 monta o compartilhamento NFS, o log do servidor mostra êxito:
Feb 11 20:06:46 mandrake mountd[460]: authenticated mount request from atlhon64.acme.local:770 for /data (/data)
Mas quando o host C tenta montar o mesmo compartilhamento, o log do servidor mostra:
Feb 11 20:12:42 mandrake mountd[460]: refused mount request from lap-fzs-2 for /data (/): no export entry
O host C vê o servidor, alcança o portmapper e o nfsd, mas falha nas permissões.
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
Eu tenho que usar o NFSv2 no cliente. O uso do NFSv4 falhará, pois o servidor não o suporta. Ele falha ao tentar conectar-se via TCP diretamente a 2049, mas a porta não está aberta. Nenhum fallback acontece. O uso do NFSv3 resultará em uma incompatibilidade de programa / versão do RPC.
o que estou perdendo?
Atualização:
Todas as três máquinas estão em uma LAN, no mesmo switch. Não há firewall ativo no 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
Nem no host A:
[root@mandrake /root]# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
exportfs -acomando no host A e tente o mountcomando no host C. Tente o nome do host explícito ou o endereço IP completo em /etc/exports.
exportfs -ano momento da inicialização e, como essa não é uma entrada nova, ela já foi exportada. O arquivo de exportação não mudou, é apenas um novo host que deve montá-lo e não pode.
/etc/exportsverdade faz com que funcione. Agora tenho a rede / 24 mais o IP completo listado e o host C pode montar. Ainda não tentei hospedar B. Alguma ideia do porquê disso? Notei que o host B (o que funcionava) usava uma chamada MNT da versão 2, enquanto o host C recorria a uma chamada MNT da versão 1.