Este problema básicamente me está volviendo loco en este momento. Tengo un servidor NFS Ubuntu 16.04 que funcionaba bien con esta configuración:
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
y
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Todo esto ha estado funcionando bien durante meses en el único cliente nfs que usa esta configuración hasta ahora usando estas entradas /etc/fstab del lado del cliente:
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
Sin embargo, dado que se trata de un servidor de almacenamiento muy grande, se decidió que necesita albergar varios laboratorios. Entonces, moví todo el material que había estado disperso en la partición /data2 a un subdirectorio /data2/cryodata y actualicé /etc/fstab en el servidor y /etc/exports de la siguiente manera:
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
y
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
¡Esto simplemente no funciona! Cuando intento montar el nuevo montaje en el cliente usando la misma entrada /etc/fstab del cliente:
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
.
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
El /usr/local continúa montando sin problemas. La primera vez que intenté esto, olvidé desexportar/exportar los sistemas de archivos utilizados exportfs -varantes de realizar cambios, pero desde entonces he cambiado de un lado a otro, teniendo cuidado de desexportar y desmontar todo, con varios reinicios del servidor en el medio. El montaje original de un montaje de enlace de toda la partición siempre funciona, y el montaje de enlace de un subdirectorio falla con el mensaje de identificador nfs obsoleto cada vez. Intenté habilitar otros clientes nfs que nunca montaron estas particiones y recibí exactamente el mismo mensaje de error: en este caso definitivamente es un problema del lado del servidor. Revisé /var/lib/nfs/etab para asegurarme de que se borre entre intentos de montaje, etc.
Pensé que la técnica de montaje enlazado en el directorio raíz de un servidor nfs resolvía todo este tipo de problemas, pero aparentemente no. Lo extraño es que /usr/local es un subdirectorio de otra partición y siempre se monta bien. Está en un ext3 md raid 1, aunque no creo que esto importe.
He pasado horas en esto y casi rompo Google buscando una solución sin éxito.
Respuesta1
Tenga en cuenta que sólo estoy exportando sistemas de archivos montados en enlace. Esta sección de laexportacionesLa página de manual es relevante:
fsid=núm|raíz|uuid
NFS debe poder identificar cada sistema de archivos que exporta. Normalmente utilizará un UUID para el sistema de archivos (si el sistema de archivos tiene tal cosa) o el número de dispositivo del dispositivo que contiene el sistema de archivos (si el sistema de archivos está almacenado en el dispositivo).
Mi suposición errónea fue que los sistemas de archivos montados en enlace tienen algún tipo de UUID que NFS puede usar automáticamente; y suposición reforzada por el hecho de que ambas exportaciones montadas en vínculos funcionaron bien sin un fsid:
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Sin embargo, esto da como resultado un comportamiento inconsistente. Agregué un enlace montado /opt:
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
resultó en un comportamiento inconsistente; es decir, podría cambiar la IP de exportación y montarla en una máquina, pero obtener el permiso denegado en otra. La solución fue agregar un fsid:
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
Entonces, la solución es agregar siempre un fsid para exportar sistemas de archivos montados en enlace.