El montaje NFS falla, permiso denegado, no hay entrada de exportación

10

Tengo un problema al montar un recurso compartido NFS que no puedo resolver y que me está volviendo loco. Esta es la situación:

Tres máquinas involucradas:
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

El host A tiene un servidor NFS en ejecución que exporta un directorio que es montado por el host B. Esto funciona perfectamente y ha estado funcionando desde hace siglos. No hay problema. Ahora el host C entra en escena. Ubuntu 12.04 LTS, sistema moderno. Intenté montar el mismo recurso compartido desde el host A pero recibí un error de permiso denegado:

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

El hecho de que funcione entre los hosts A y B debe demostrar que la exportación NFS per se está funcionando. Aquí está la información que puedo dar que me hace pensar que debería funcionar. Tal vez alguien vea lo que yo no y sepa por qué esto falla en el nuevo host C.

Exportaciones de 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

El portmapper se está ejecutando, las exportaciones son conocidas y montadas por el host 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

Cuando el host athlon64 monta el recurso compartido NFS, el registro del servidor muestra el éxito:

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

Pero cuando el host C intenta montar el mismo recurso compartido, el registro del servidor muestra:

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

El host C ve el servidor, alcanza el portmapper y el nfsd, pero falla en los permisos.

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

Tengo que usar NFSv2 en el cliente. El uso de NFSv4 fallará ya que el servidor no lo admite. Falla al intentar conectarse a través de TCP directamente a 2049 pero el puerto no está abierto. No se produce un retroceso. El uso de NFSv3 dará como resultado un programa RPC / desajuste de versión.

¿Qué me estoy perdiendo?

Actualización:
las tres máquinas están en una LAN, en el mismo conmutador. No hay firewall activo en el 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

Ni en el host A:

[root@mandrake /root]# ipchains -L 
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
linux nfs Florian
fuente
¿Cortafuegos en el host C (o menos probable host A)? (¿Qué muestra / sbin / iptables -vnL?)
davidgo
No, sin firewalls, un segmento LAN.
Florian
1
pruebe el exportfs -acomando en el Host A, luego intente el mountcomando en el Host C. Pruebe el nombre de host explícito o la dirección IP completa en /etc/exports.
aserrín
1
¿Cómo ayudaría eso? El servidor realiza un exportfs -aarranque durante el arranque y, dado que no se trata de una entrada nueva, ya se exportó. El archivo de exportaciones no cambió, es solo un nuevo host que debería montarlo y no puede.
Florian
@sawdust su edición contenía la pista correcta: usar la dirección IP completa en /etc/exportsrealidad lo hace funcionar. Ahora tengo / 24 net más la IP completa listada y el host C puede montarse. No he probado el host B todavía. ¿Alguna idea de por qué es esto? Noté que el host B (el que funcionaba) usó una llamada MNT de la versión 2, mientras que el host C recurrió a una llamada MNT de la versión 1.
Florian

Respuestas:

0

11 de febrero 20:12:42 mandrake mountd [460]: solicitud de montaje rechazada de lap-fzs-2 para / data (/): sin entrada de exportación

Dado que el aviso de rechazo del servidor afirma que "no hay entrada de exportación" para el Host C, entonces quizás debería intentar una línea inequívoca en el /etc/exportsarchivo con el nombre de host explícito o la dirección IP completa para C.

También intente emitir un exportfs -acomando en el servidor.
A menudo tengo problemas para acceder a mi servidor NFS incluso después de reiniciar. Expedir explícitamente el exportfs -acomando es la solución confiable (para mí).

serrín
fuente
Lo explícito, repetido exportfs -ano cambió nada para mí. El uso de la dirección IP completa para el host problemático resolvió mi problema. Entonces, aunque esto no lo explica y no lo entiendo, fue la respuesta a mi problema y lo que puedo recomendar probar para otros con el mismo problema.
Florian
Agregar una entrada para la dirección IP problemática en / etc / exports también resolvió mi problema. Extraño.
PLA
1

Compruebe y vea si el UID y el GUID para los usuarios de NFS son iguales en el servidor y el cliente. Además, asegúrese de que en el servidor la carpeta tenga el permiso 777. Este es mi / etc / exportaciones en mi servidor para que mi cliente acceda.

Cree un directorio compartido NFS: (Cree cada servidor con IP, espacio separado)

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
fuente
El UID y el GID no son lo mismo. No tienen que serlo, funciona una vez que tengo el recurso compartido montado en el cliente NFS. Y para la operación de montaje, los UID del usuario deben ser irrelevantes. Dudo que configurar la carpeta en 777 sea una buena idea, especialmente si los usuarios pueden iniciar sesión en el servidor. Una vez más, funcionó sin eso una vez que lo monté.
Florian
1

En mi caso, -o vers = 3 es la respuesta:

$ sudo mount -o vers=3 192.168.172.1:/A/DIR /mnt
  • Servidor NFS: Ubuntu escritorio 12.04 host vmware de 32 bits
  • Cliente NFS: Servidor Ubuntu 12.04 invitado vmware de 64 bits (modo solo host)
Fumisky Wells
fuente