Montar recursos compartidos NFS de forma robusta: hard frente a soft, timeo, y qué ocurre cuando el servidor desaparece

Objetivo

Montar una exportación NFS de una forma que sobreviva a un servidor que no responde y a un reinicio normal, y saber qué paquete y versión usar en RHEL frente a Debian/Ubuntu.

Requisitos previos

• Privilegios de root para montar. Paquetes de cliente: nfs-utils en RHEL/Fedora, nfs-common en Debian/Ubuntu.
• La ruta de exportación y la dirección del servidor; showmount -e <server> lista las exportaciones del servidor (requiere que mountd/rpcbind sean accesibles, algo relevante sobre todo en NFSv3).

Pasos

1. Comprobar qué ofrece el servidor: showmount -e nfsserver. showmount depende de mountd/rpcbind y puede no mostrar nada contra un servidor solo NFSv4 aunque los montajes funcionen. NFSv4 presenta las exportaciones en un único pseudosistema de archivos y no necesita rpcbind; NFSv3 sí necesita rpcbind, y el cliente recurre a él solo si el servidor no ofrece NFSv4 o si se establece vers=3.
2. Montar una vez manualmente para probar: mount -t nfs -o vers=4.2 nfsserver:/export /mnt/data (sin vers=/nfsvers=, mount -t nfs negocia la versión más alta que ambos lados admiten; vers=4.2 falla si el servidor no ofrece 4.2).
3. Elegir deliberadamente el comportamiento ante fallos en /etc/fstab:
   • hard (el predeterminado): la E/S en el montaje se bloquea y reintenta indefinidamente si el servidor deja de responder; un proceso atascado en una llamada NFS en este estado generalmente solo termina con SIGKILL (la opción heredada intr se ignora desde el kernel 2.6.25). Esto protege contra la pérdida silenciosa de datos en una interrupción transitoria.
   • soft: la E/S se rinde tras retrans= retransmisiones (cada una esperando timeo= décimas de segundo, con retroceso lineal sobre TCP) y devuelve un error a la aplicación —apropiado solo cuando la aplicación ya maneja correctamente los errores de E/S, ya que soft puede corromper silenciosamente un estado que asumía que las escrituras habían tenido éxito.
   • Sobre TCP los valores predeterminados ya son timeo=600 (60 segundos) y retrans=2; aumentar retrans= amplía la ventana antes de que un montaje soft se rinda ante enlaces inestables.
4. Orden de red: systemd ya reconoce nfs/nfs4 como sistemas de archivos de red y los ordena después de la red; _netdev solo es necesario cuando esa detección falla (por ejemplo, sistemas de archivos respaldados por iSCSI) y es inofensivo en una línea NFS.
5. Para evitar que el arranque se quede colgado cuando el servidor NFS está caído, añadir x-systemd.automount,x-systemd.mount-timeout=30 a las opciones de la entrada: el montaje solo se activa en el primer acceso, con un tiempo de espera acotado, en lugar de bloquear la secuencia de arranque (nofail por sí solo también evita que el arranque lo espere). Tras editar fstab, ejecutar systemctl daemon-reload.
6. Montar todo desde fstab y verificar: mount -a, luego mount | grep nfs y nfsstat --client para las estadísticas RPC del lado del cliente (las retransmisiones aquí indican una ruta inestable incluso cuando el montaje parece funcionar).

Resultado esperado

El recurso compartido es accesible, mount -a termina sin quedarse colgado, y un servidor NFS detenido deliberadamente produce el comportamiento elegido (reintento indefinido para hard, un error acotado para soft) en lugar de un cuelgue de arranque no planificado.

Límites y base de verificación

Opciones verificadas contra nfs(5), mount.nfs(8) y systemd.mount(5) (_netdev, x-systemd.automount). Para deshacer: comentar o eliminar la línea de fstab y umount /mnt/data; desmontar no afecta a ningún dato del cliente.