Debian 13: SSHFS vs NFS — elige el que no se bloquee al azar (y configúralo bien)

La decisión con opinión: usa NFS para producción, SSHFS para casos puntuales

Si tu objetivo es “no se bloqueará al azar”, elige NFS con systemd automount para cualquier cosa que se parezca a almacenamiento compartido en producción.
SSHFS es excelente cuando necesitas cifrado sin infraestructura, cuando tiras datos de una máquina que no controlas,
o cuando quieres un montaje rápido tipo parche para una tarea puntual. Pero si montas SSHFS como una dependencia central y esperas que se comporte como un servidor de archivos LAN,
te vas a encontrar con las semánticas de FUSE, los fallos TCP y el buffering en espacio de usuario de la forma menos simpática posible.

NFS no es magia. También puede colgar —especialmente con montajes hard (el predeterminado)— porque “no devolver datos corruptos” es un principio respetable.
Pero la diferencia es que NFS te da mejor herramienta, mejor integración en el kernel y perillas claras para el comportamiento ante fallos.
La mayoría de los “bloqueos aleatorios” no son aleatorios; son elegir semánticas bloqueantes sin una salida.

Regla práctica:

• Usa NFSv4.2 para directorios home compartidos, artefactos de compilación, zonas de aterrizaje de backups y “múltiples clientes necesitan los mismos datos”.
• Usa SSHFS para acceso ad-hoc, atravesar redes hostiles o cuando necesitas autenticación por usuario sin montar NFS correctamente.
• Nunca montes cualquiera de los dos de forma que bloquee el arranque o detenga daemons críticos. Automount o orden explícita de dependencias, siempre.

Una cita para mantenerte honesto. Werner Vogels (CTO de Amazon) tiene una idea muy citada—parafraseada: “Todo falla, todo el tiempo.”
Si aceptas eso, dejas de tratar los bloqueos como misterios y empiezas a diseñar el modo de fallo con el que puedas vivir.

Hechos e historia que importan en 2025

Unos puntos de contexto que puedes usar en reuniones cuando alguien insiste “es solo un montaje, ¿qué tan difícil puede ser?”

1. NFS tiene edad y cicatrices. Se remonta a mediados de los 80 en Sun Microsystems, y su diseño refleja dolores empresariales reales: archivos UNIX compartidos a escala.
2. NFSv4 fue una reescritura en espíritu. Consolidó protocolos, mejoró seguridad y estado, y avanzó hacia “un puerto amigable con firewalls”.
3. NFS solía amar UDP. Los despliegues antiguos usaban UDP; la práctica moderna recomienda TCP para fiabilidad y control de congestión.
4. SSHFS es FUSE. Eso significa plumbing en espacio de usuario; genial para flexibilidad, no para “almacenamiento siempre activo a nivel kernel”.
5. Las semánticas de FUSE pueden sorprender. Comprobaciones de permisos, caché y propagación de errores se comportan distinto que en sistemas de ficheros de kernel—especialmente bajo fallo.
6. El cliente NFS es muy dependiente de políticas. “Hard” vs “soft”, timeouts, retransmisiones y caché de atributos moldean cómo se siente un “bloqueo”.
7. Systemd cambió las reglas. Unidades automount y dependencias de montaje permiten mantener el arranque y servicios vivos aunque el almacenamiento sea inestable.
8. El bloqueo ha sido históricamente un lío. El locking en NFS pasó por gestores de bloqueo separados; NFSv4 integró bloqueo, pero supuestos legacy aún aparecen en aplicaciones.
9. Mapeo de identidades es una trampa escondida. NFSv4 usa mapeo por nombre a menos que lo configures; desajustes parecen “permisos que se rompieron aleatoriamente”.

Qué significa realmente “bloqueo aleatorio” (y quién tiene la culpa)

Cuando los ingenieros dicen “SSHFS se colgó” o “NFS se colgó”, normalmente se refieren a una de cuatro cosas:

1) Un proceso está en estado D (sueño no interrumpible)

Ese es el clásico: ps muestra D, kill -9 no hace nada, y lo único que “lo arregla” es restaurar el servidor remoto o reiniciar.
Esto es más común con montajes NFS hard durante una caída del servidor o partición de red.

2) La llamada de montaje se bloquea para siempre

Bloqueos en el arranque, o un servicio que no arranca, porque algo intentó montar un sistema de ficheros remoto y esperó. Esto es una falla de configuración:
sin automount, sin timeout, y una cadena de dependencias que permite que un recurso remoto tome como rehén al host.

3) Listados de directorio se cuelgan, pero algunas lecturas funcionan

Las operaciones de metadata (lookup, getattr, readdir) son sensibles al caché y a la variabilidad de la red.
SSHFS puede sentirse peor aquí porque cada operación de metadata es un ida y vuelta por un canal SSH, más la sobrecarga del protocolo SFTP.
NFS también puede hacerlo si la caché de atributos está mal ajustada o el servidor está sobrecargado.

4) “Está lento” parece “está colgado”

Un bloqueo de 30 segundos en find o du suele ser amplificación de latencia:
miles de pequeñas operaciones de metadata por unos pocos milisegundos cada una equivalen a “mi terminal murió”.

Broma #1: Un sistema de ficheros remoto es como un compañero de trabajo de vacaciones—técnicamente sigue empleado, pero no obtienes respuesta antes del almuerzo.

¿Quién es más probable que “se bloquee al azar”?

SSHFS es más propenso a desconectarse o entorpecerse impredeciblemente en redes poco fiables, especialmente si no configuras keepalives.
Pero cuando SSHFS falla, a menudo falla “más suave” (obtienes errores de E/S, el montaje desaparece, la reconexión puede funcionar) en vez de atrapar al kernel en reintentos infinitos.

NFS es más propenso a bloquear para siempre por diseño con montajes hard por defecto. Eso no es aleatorio; es política.
Si quieres “no colgar todo el host”, diseñas el modo de fallo: automount, timeouts cuando proceda,
y una decisión clara sobre hard vs soft por carga de trabajo.

Playbook de diagnóstico rápido (primero/segundo/tercero)

Este es el “tengo cinco minutos antes de que esto se convierta en sala de guerra”. El objetivo es identificar si tratas con
(a) alcanzabilidad de red, (b) carga o fallo del daemon en el servidor, (c) semánticas de montaje en el cliente, o (d) rarezas de DNS/identidad.

Primero: confirma que no es alcanzabilidad básica

• ¿Puedes hacer ping a la IP del servidor (o al menos resolver el nombre)?
• ¿Es alcanzable el puerto TCP 2049 para NFSv4? ¿Es alcanzable el TCP 22 para SSHFS?
• ¿Hay pérdida de paquetes o alta latencia que convierta metadata en melaza?

Segundo: revisa si el cliente está bloqueado en E/S de kernel

• ¿Hay procesos atascados en estado D?
• ¿cat /proc/mounts o mount se cuelga?
• ¿Acceder a otros sistemas de ficheros funciona con normalidad?

Tercero: interroga la ruta de protocolo específica

• Para NFS: nfsstat, rpcinfo (si v3), logs del kernel, estado de exportación del servidor y si el servidor está respondiendo.
• Para SSHFS: keepalives de SSH, salud del subsistema SFTP y si la conexión SSH está atascada por una sesión TCP muerta.

Puntos de decisión

• Si el servidor es inalcanzable: automount evita la paralización total del host; arregla la red o conmute a un failover.
• Si el servidor es alcanzable pero lento: estás limitado por capacidad—CPU, discos o demasiados clientes; afina y escala.
• Si un cliente se cuelga pero otros no: sospecha DNS en el cliente, mapeo de identidades o un estado de montaje bloqueado.

Tareas prácticas: comandos, salidas y qué decisión tomar

Estos son los movimientos de on-call que separan “creo que es NFS” de “el cliente está en reintento duro porque el servidor dejó de responder COMPOUND ops.”
Cada tarea incluye: comando, qué significa la salida y qué haces después.

Task 1: Ver qué está montado y si tratas con NFS o FUSE

cr0x@server:~$ findmnt -t nfs,nfs4,fuse.sshfs
TARGET        SOURCE                 FSTYPE     OPTIONS
/mnt/shared   nas01:/export/shared   nfs4       rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21
/mnt/adhoc    devbox:/home/builds    fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000

Significado: tienes ambos. NFS es del kernel; SSHFS es FUSE. Decisión: aplica las herramientas adecuadas—nfsstat para NFS, logs de SSH para SSHFS.

Task 2: Comprueba si procesos están en E/S no interrumpible (estado D)

cr0x@server:~$ ps -eo state,pid,comm,wchan:30 | awk '$1=="D"{print}'
D  18472 rsync  nfs_wait_bit_killable
D  21205 du     rpc_wait_bit_killable

Significado: están bloqueados en esperas del kernel, típico del comportamiento de reintento duro de NFS. Decisión: deja de esperar que kill -9 ayude; restaura servidor/red o desmonta con cuidado.

Task 3: Confirma la ruta de red rápidamente (latencia y pérdida)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.0.0.50) 56(84) bytes of data.
64 bytes from 10.0.0.50: icmp_seq=1 ttl=63 time=0.453 ms
64 bytes from 10.0.0.50: icmp_seq=2 ttl=63 time=0.482 ms
64 bytes from 10.0.0.50: icmp_seq=3 ttl=63 time=12.103 ms
64 bytes from 10.0.0.50: icmp_seq=4 ttl=63 time=0.469 ms
64 bytes from 10.0.0.50: icmp_seq=5 ttl=63 time=0.476 ms

--- nas01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4093ms
rtt min/avg/max/mdev = 0.453/2.797/12.103/4.650 ms

Significado: un pico. Eso puede ser suficiente para que cargas con mucha metadata se perciban como “colgadas”. Decisión: si los picos correlacionan con bloqueos, busca congestión, bufferbloat o problemas de NIC.

Task 4: Para NFSv4, verifica accesibilidad del puerto (2049)

cr0x@server:~$ nc -vz -w2 nas01 2049
Connection to nas01 (10.0.0.50) 2049 port [tcp/nfs] succeeded!

Significado: conectividad básica OK. Decisión: deja de culpar al firewall; revisa carga del servidor, salud del daemon NFS o semánticas de montaje en el cliente.

Task 5: Para SSHFS, confirma salud del transporte SSH y velocidad de autenticación

cr0x@server:~$ ssh -o BatchMode=yes -o ConnectTimeout=5 build@devbox 'echo ok'
ok

Significado: SSH responde. Decisión: si SSH está bien pero SSHFS se atasca, céntrate en el subsistema SFTP, keepalives y comportamiento FUSE bajo carga.

Task 6: Inspecciona logs del kernel por timeouts NFS y servidor no responde

cr0x@server:~$ sudo journalctl -k -n 20
Aug 12 14:03:19 app01 kernel: nfs: server nas01 not responding, still trying
Aug 12 14:03:50 app01 kernel: nfs: server nas01 not responding, still trying
Aug 12 14:04:23 app01 kernel: nfs: server nas01 OK

Significado: el “bloqueo” es el cliente haciendo exactamente lo que le pediste: seguir intentando. Decisión: si esto bloquea producción, añade automount y considera soft solo para lecturas no críticas.

Task 7: Ver estadísticas por montaje NFS (retransmisiones son el humo)

cr0x@server:~$ nfsstat -m
/mnt/shared from nas01:/export/shared
 Flags:	rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21
 Stats:	age: 00:43:11  ops/s: 127
	xprt:	tcp  90632  211  0  0  0
	per-op statistics
	READ: 42.1%  WRITE: 11.7%  GETATTR: 20.4%  LOOKUP: 14.2%  ACCESS: 7.6%

Significado: la línea de transporte muestra retransmisiones (el segundo número tras las llamadas). Si retrans sube, estás perdiendo respuestas. Decisión: investiga pérdida de red, saturación del servidor o timeouts demasiado agresivos.

Task 8: Identificar si DNS causa stalls (consultas inversas pueden perjudicar)

cr0x@server:~$ getent hosts nas01
10.0.0.50       nas01

Significado: el nombre resuelve rápido. Decisión: si esto se cuelga o devuelve direcciones inesperadas, arregla DNS antes de tocar montajes.

Task 9: Revisar exports en servidor (desde el servidor)

cr0x@nas01:~$ sudo exportfs -v
/export/shared  10.0.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)

Significado: el export existe; root está squasheado; sync habilitado. Decisión: si los clientes necesitan semántica de root, no “arregles” con all_squash inseguro—usa mapeo UID/GID apropiado o una cuenta de servicio.

Task 10: Confirmar servicios del servidor NFS están activos (servidor)

cr0x@nas01:~$ systemctl status nfs-server --no-pager
● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2025-08-12 13:01:21 UTC; 3h 2min ago
       Docs: man:nfsd(8)

Significado: servicio “active (exited)” que es normal para algunas unidades nfs-server una vez que se generan hilos del kernel. Decisión: si ha fallado, no depures clientes—arregla el servidor primero.

Task 11: Detectar un montaje que colgará tu shell (prueba un stat con timeout)

cr0x@server:~$ timeout 3 stat /mnt/shared || echo "stat timed out"
stat timed out

Significado: la llamada de metadata se bloqueó más de 3 segundos. Decisión: tu app que hace llamadas al sistema de ficheros también se bloqueará; evita esto haciendo failover, desmontando o aislando la dependencia.

Task 12: Intentar un unmount lazy con seguridad (cuando el remoto no responde)

cr0x@server:~$ sudo umount -l /mnt/shared

Significado: la falta de salida suele indicar éxito. El desmontaje lazy desacopla el punto de montaje ahora y limpia cuando desaparezcan referencias. Decisión: úsalo cuando necesites el box utilizable de inmediato; luego arregla la causa subyacente.

Task 13: Forzar un remount limpio con systemd (cliente)

cr0x@server:~$ sudo systemctl restart mnt-shared.mount

Significado: systemd reevalúa la unidad de montaje. Decisión: si el reinicio se bloquea, cambia a automount para que el montaje ocurra bajo demanda y pueda expirar sin retener arranque/inicio de servicio.

Task 14: Para SSHFS, revisar sesiones TCP muertas y comportamiento de keepalive

cr0x@server:~$ ss -tpn '( sport = :ssh or dport = :ssh )'
ESTAB 0 0 10.0.0.21:52418 10.0.0.60:22 users:(("ssh",pid=29102,fd=3))

Significado: existe conexión SSH. Decisión: si está ESTAB pero la E/S está bloqueada, probablemente tengas un camino medio-muerto (middlebox con estado, NAT, Wi‑Fi en suspensión). Añade keepalives y ServerAliveInterval para SSHFS.

NFS que no te avergüence: configuraciones servidor + cliente en Debian 13

La reputación de NFS es extraña: o “muy sólido” o “embrujado”. En producción, depende de si lo tratas como un componente del sistema
(con identidad, exports y automount) o como una línea de montaje copiada de una wiki de 2009.

Servidor: instalar y exportar de forma sensata

En el servidor NFS (Debian 13), quieres un export simple, TCP y permisos predecibles. Si necesitas seguridad fuerte a través de redes no confiables,
usa Kerberos; para LANs confiables, sec=sys es común y está bien si tu red es realmente de confianza.

cr0x@nas01:~$ sudo apt update
Hit:1 ... InRelease
Reading package lists... Done

cr0x@nas01:~$ sudo apt install -y nfs-kernel-server
Reading package lists... Done
...
Setting up nfs-kernel-server ...

Crea un export. Las banderas importan:
sync intercambia algo de rendimiento por integridad; para muchas cargas empresariales esa es la elección correcta.
no_subtree_check evita comprobaciones basadas en rutas molestas (y sorpresas durante renombres).
Manténlo restringido: una subred o un conjunto de hosts.

cr0x@nas01:~$ sudo mkdir -p /export/shared
cr0x@nas01:~$ sudo chown -R root:root /export
cr0x@nas01:~$ sudo chmod 755 /export /export/shared

cr0x@nas01:~$ sudo tee /etc/exports >/dev/null <<'EOF'
/export/shared 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
EOF
cr0x@nas01:~$ sudo exportfs -ra
cr0x@nas01:~$ sudo exportfs -v
/export/shared  10.0.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)

Cliente: monta con NFSv4.2 y elige tus semánticas de fallo

La elección clave es hard vs soft:

• hard: reintenta indefinidamente. Más seguro para la corrección de datos. También fuente clásica de “el host parece colgado”.
• soft: devuelve error después de reintentos. Mejor para clientes interactivos y lecturas no críticas. Peligroso para apps que no manejan fallos parciales.

En producción, por defecto elijo hard + automount. Así no corrompes flujos de trabajo, y no atas el arranque.
Para herramientas no críticas (como una máquina de desarrollo listando un share de medios), soft puede ser aceptable.

cr0x@server:~$ sudo apt install -y nfs-common
Reading package lists... Done
...
Setting up nfs-common ...

Prueba un montaje manual para validar lo básico.

cr0x@server:~$ sudo mkdir -p /mnt/shared
cr0x@server:~$ sudo mount -t nfs4 -o vers=4.2,proto=tcp,hard,timeo=600,retrans=2 nas01:/export/shared /mnt/shared
cr0x@server:~$ mount | grep /mnt/shared
nas01:/export/shared on /mnt/shared type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.21)

Qué significan esas opciones en la práctica:

• proto=tcp: quieres TCP a menos que disfrutes depurar pérdida de paquetes “funciona en mi escritorio”.
• timeo=600: para TCP, esto está en décimas de segundo. 600 → 60s por intento RPC. Eso es conservador.
• retrans=2: número de reintentos antes de escalar la lógica de timeout. No “reintentos totales” para montajes hard; los montajes hard pueden seguir intentando.
• rsize/wsize: tamaños grandes ayudan el rendimiento, pero no arreglan la latencia de metadata. No curan un “find lento”.

Permisos e identidad: hazlo aburrido

NFS no es un sistema de permisos; reenvía identidad. Si UID/GID no coinciden entre máquinas, obtienes denegaciones “aleatorias”.
Arréglalo en la fuente: UID/GID consistentes para cuentas de servicio y usuarios compartidos.

SSHFS que se comporte: keepalives, systemd y caché sensata

SSHFS atrae porque es solo SSH. Sin exports, sin nostalgia de rpcbind, sin reuniones de firewall especiales.
Pero SSHFS vive en espacio de usuario, habla SFTP y depende de una sesión SSH estable. Es un sistema de ficheros muy educado: pide permiso por todo,
una pregunta a la vez, sobre un túnel cifrado. Esa educación es cara.

Instalar y hacer un montaje básico

cr0x@server:~$ sudo apt install -y sshfs
Reading package lists... Done
...
Setting up sshfs ...

cr0x@server:~$ mkdir -p /mnt/adhoc
cr0x@server:~$ sshfs build@devbox:/home/builds /mnt/adhoc -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,Compression=no
cr0x@server:~$ findmnt /mnt/adhoc
TARGET     SOURCE              FSTYPE     OPTIONS
/mnt/adhoc build@devbox:/home/builds fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000

Las opciones de keepalive son innegociables si hay NAT, Wi‑Fi o “appliances de seguridad” entre tú y el servidor:
ServerAliveInterval envía pings a nivel SSH; reconnect intenta restablecer la sesión.

Broma #2: SSHFS es como pasar un archivador por seguridad de aeropuerto—todo se inspecciona y pagas por el privilegio.

Patrones comunes de cuelgue en SSHFS

• Sesiones TCP medio abiertas: tu portátil durmió, el NAT expiró, la conexión parece ESTAB pero no fluyen paquetes. Keepalives reducen el tiempo de detección.
• Problemas en el subsistema SFTP: sftp-server remoto lento, con pocos recursos o constreñido por comandos forzados.
• Contención de hilos FUSE: llamadas paralelas intensas pueden colapsar el daemon en espacio de usuario; picos de CPU en el cliente parecen “montaje colgado”.

Opciones de montaje SSHFS que reducen dolor

• reconnect: intenta reconectar si la conexión cae.
• ServerAliveInterval=15 y ServerAliveCountMax=3: detectar sesiones muertas rápidamente.
• workaround=rename (a veces): ayuda con apps que hacen renombres atómicos y golpean casos límite.
• cache=yes o kernel_cache: puede mejorar el rendimiento pero perjudica la coherencia. Úsalo con cuidado si hay múltiples escritores.
• Compression=no en LAN rápida: ahorra CPU y suele mejorar la latencia.

Si varios clientes escriben los mismos ficheros y te importa la consistencia, la caché de SSHFS es una trampa.
NFS tiene su propia historia de caché/coherencia, pero está diseñado para acceso multi-cliente. SSHFS está diseñado para acceso, no para coordinación.

Deja de colgar el arranque: patrones de automount con systemd

El “bloqueo aleatorio” más evitable es el que ocurre al arranque porque /etc/fstab dijo al host que bloquee hasta que una máquina remota responda.
No hagas eso. Usa systemd automount para que el montaje ocurra en el primer acceso y para que los timeouts no inutilicen el host.

NFS con /etc/fstab y systemd automount

Pon esto en /etc/fstab en el cliente. Monta bajo demanda, no en el arranque:

cr0x@server:~$ sudo tee -a /etc/fstab >/dev/null <<'EOF'
nas01:/export/shared /mnt/shared nfs4 nofail,x-systemd.automount,x-systemd.device-timeout=10s,x-systemd.mount-timeout=10s,_netdev,vers=4.2,proto=tcp,hard,timeo=600,retrans=2 0 0
EOF

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart remote-fs.target
cr0x@server:~$ systemctl status mnt-shared.automount --no-pager
● mnt-shared.automount - /mnt/shared
     Loaded: loaded (/etc/fstab; generated)
     Active: active (waiting) since Tue 2025-08-12 14:10:12 UTC; 2s ago

Significado: automount está armado y esperando. Decisión: este host puede arrancar aunque nas01 esté caído; el primer acceso dispara un intento de montaje con timeouts.

SSHFS con systemd (preferible a fstab para montajes de usuario)

SSHFS a menudo funciona mejor como servicio de usuario o con unidades systemd explícitas, porque es un proceso en espacio de usuario y quieres manejo de ciclo de vida limpio.
Aquí hay un ejemplo de unidad a nivel de sistema si quieres montarlo para una cuenta de servicio (ajusta user/rutas según necesites).

cr0x@server:~$ sudo tee /etc/systemd/system/mnt-adhoc.mount >/dev/null <<'EOF'
[Unit]
Description=SSHFS mount for /mnt/adhoc
After=network-online.target
Wants=network-online.target

[Mount]
What=build@devbox:/home/builds
Where=/mnt/adhoc
Type=fuse.sshfs
Options=_netdev,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,Compression=no,IdentityFile=/home/build/.ssh/id_ed25519

[Install]
WantedBy=multi-user.target
EOF
cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now mnt-adhoc.mount
Created symlink /etc/systemd/system/multi-user.target.wants/mnt-adhoc.mount → /etc/systemd/system/mnt-adhoc.mount.

Decisión: si ves que este montaje a veces se queda bloqueado, añade una unidad .automount acompañante y móntalo bajo demanda—mismo principio que NFS.

Tres microhistorias corporativas del “debería haber funcionado”

Incidente por una suposición errónea: “Los montajes hard no pueden dañarnos”

Una empresa mediana tenía servidores de aplicaciones Debian que extraían assets estáticos y algunos fragmentos de configuración desde un share NFS.
La suposición era sencilla: los montajes hard previenen lecturas corruptas, así que son “más seguros”. Alguien incluso argumentó que un bloqueo es mejor que datos malos,
lo cual es verdadero en abstracto y falso en medio de una caída que afecta a clientes.

Durante una ventana de mantenimiento, el equipo de almacenamiento reinició el servidor NFS. El reinicio tardó más de lo esperado porque la máquina ejecutó un fsck.
Mientras tanto, los servidores de aplicaciones siguieron funcionando, hasta que un deploy disparó un script que hizo un find recursivo sobre la ruta montada.
De pronto, todos los agentes de deploy quedaron atascados. Luego el agente de monitoring trató de leer un archivo bajo esa ruta. Luego un hook de logrotate hizo lo mismo.

La “suposición errónea” fue pensar que un bloqueo por hard mount es local. No lo fue. El punto de montaje formaba parte de demasiados caminos de código.
El resultado no fue solo un job bloqueado; fue una flota entera acumulando procesos atascados y carga por tormentas de reintentos.
Algunos nodos se degradaron hasta que el orquestador empezó a hacer flapping con servicios.

La solución no fue “usar soft mounts por todas partes”. Fue automount más un rediseño: dejar de poner dependencias de runtime críticas en un sistema de ficheros remoto
a menos que la aplicación tolere explícitamente que esa dependencia sea lenta o no esté disponible. Los montajes hard se mantuvieron para los datos que realmente los necesitaban,
pero el acceso pasó a ser bajo demanda y con límites temporales en el layer de systemd.

Optimización que se volvió contra ellos: “Subamos caché y rsize/wsize al máximo”

Otro equipo tenía una granja de builds leyendo artefactos grandes desde un almacén compartido. Alguien hizo lo sensato: aumentó rsize/wsize a 1 MiB,
activó caché agresiva en el cliente y declaró victoria tras un benchmark que copió unos pocos ficheros multi-gig rápidamente.
El dashboard mejoró. La gente aplaudió. El cambio se desplegó.

Luego empezó la rareza. Los builds empezaron a fallar intermitentemente con “file not found” durante pasos que esperaban que un fichero apareciera justo después de que otro job lo subiera.
A veces el fichero estaba pero con timestamp más antiguo. A veces el listado de directorio no lo incluía por segundos.
Parecía consistencia eventual, que no es una frase que quieras asociada a un sistema de ficheros tipo POSIX.

Lo que salió mal fue mezclar cargas: el mismo share servía lecturas secuenciales grandes y coordinación sensible a metadata.
La caché afinada para throughput hizo que la visibilidad de metadata se retrasara. El sistema no “se colgó”; mintió educadamente por un momento.
Eso es peor que un bloqueo porque genera bugs fantasma.

Recuperaron separando las cargas: un export NFS afinado para artefactos grandes, otro path para coordinación con semánticas de caché más estrictas,
y pasar a versionado explícito de artefactos para que los lectores no dependieran de “el último fichero en un directorio” apareciendo al instante.
Lección: el tuning de rendimiento no es universal; depende de la carga, y las cargas mixtas castigan el optimismo.

Práctica aburrida pero correcta que salvó el día: automount + dependencias enjauladas

Una organización financiera (de esas que tienen ventanas de cambio y papeleo para el papeleo) tenía servidores batch Debian
que periódicamente tiraban ficheros desde un share remoto. El share era importante, pero los servidores tenían otras tareas también.
Años antes, un ingeniero precavido insistió en dos cosas: systemd automount para todos los ficheros de red, y timeouts explícitos en intentos de montaje.
Nadie lo celebró. No era “trabajo de rendimiento”. No apareció en demos.

Una noche, el backend de almacenamiento tuvo una caída parcial—la mitad de nodos NFS eran alcanzables pero sobrecargados,
devolviendo respuestas tan lentas que activaban retransmisiones del cliente. Clientes sin automount habrían quedado bloqueados en el arranque tras un reboot,
y cualquier reinicio de servicio habría sido una ruleta.

En su lugar, los batch servers siguieron vivos. Los jobs que necesitaban el share fallaron rápido con errores claros y reintentaron más tarde.
El monitoring siguió funcionando. El acceso SSH permaneció receptivo. El incidente quedó contenido a “la pipeline batch está retrasada”, no “no podemos acceder”.

El postmortem fue aburrido. Esa fue la victoria. Las prácticas aburridas no se promocionan en presentaciones,
pero evitan que el resto de tu infraestructura participe en la caída de otra pieza.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: el arranque se cuelga o tarda minutos cuando el NAS está caído

Causa raíz: montajes bloqueantes en /etc/fstab sin nofail, automount o timeouts.

Solución: añade x-systemd.automount, nofail y timeouts; o convierte a unidades systemd explícitas.

2) Síntoma: ls en el punto de montaje nunca retorna; procesos en estado D

Causa raíz: montaje NFS hard + servidor no responde; reintentos del kernel indefinidos.

Solución: restaura servidor/red; si debes recuperar el host, usa umount -l y rediseña con automount para evitar bloqueo global.

3) Síntoma: “Permission denied” en NFS, pero la misma ruta funciona en otro cliente

Causa raíz: desajuste de UID/GID entre hosts (o inconsistencias de mapeo de id en NFSv4).

Solución: estandariza identidades; asegura UIDs consistentes; evita “arreglar” con opciones de export inseguras.

4) Síntoma: montaje SSHFS se queda atascado tras suspensión del portátil o roaming Wi‑Fi

Causa raíz: sesión SSH medio abierta; dispositivo NAT/estado expiró el flujo.

Solución: añade ServerAliveInterval/ServerAliveCountMax y reconnect; considera automount para uso bajo demanda.

5) Síntoma: SSHFS “va bien” para ficheros grandes pero es terrible para find o cargas de pequeños ficheros

Causa raíz: sobrecarga por operación SFTP; latencia de metadata amplificada.

Solución: no uses SSHFS para cargas compartidas sensibles a metadata; usa NFS o sincroniza localmente (rsync, fetch de artefactos) según el caso.

6) Síntoma: NFS se siente colgado solo en horas punta

Causa raíz: servidor sobrecargado (CPU, latencia de disco, contención de locks) o congestión de red provocando retransmisiones.

Solución: confirma con nfsstat y métricas del servidor; escala servidor, mueve datos calientes o separa exports; no “tunes” timeouts en lugar de aumentar capacidad.

7) Síntoma: montajes funcionan por IP pero no por hostname

Causa raíz: problemas DNS, demoras en reverse lookup o registros inconsistentes.

Solución: arregla DNS; apunta nombres estables; no inserte IPs en configs de flota a menos que aceptes la deuda operativa.

8) Síntoma: unmount se cuelga

Causa raíz: punto de montaje ocupado con procesos atascados manteniendo referencias; reintentos hard de NFS; daemon FUSE atascado.

Solución: identifica holders (lsof/fuser si responden), usa umount -l; para FUSE, considera parar el proceso sshfs y luego desmontar lazy.

Listas de verificación / plan paso a paso

Paso a paso: elegir el protocolo (edición realidad de producción)

1. Si varios clientes necesitan los mismos datos escribibles: elige NFSv4.2.
2. Si es acceso ad-hoc sobre redes semi-hostiles: elige SSHFS.
3. Si necesitas “almacenamiento compartido” pero la app no tolera semánticas de sistema de ficheros: no uses ninguno—usa object storage, fetch por HTTP o replica localmente.
4. Decide tu modo de fallo:
   • Prefiere hard + automount para corrección sin colgar el arranque.
   • Usa soft solo cuando la app tolere errores de E/S limpiamente.

Paso a paso: implementar NFS correctamente en Debian 13

1. Servidor: instala nfs-kernel-server.
2. Servidor: crea una ruta de export dedicada; establece ownership deliberadamente.
3. Servidor: configura /etc/exports con sync y no_subtree_check; limita clientes.
4. Cliente: instala nfs-common.
5. Cliente: prueba montaje manual con vers=4.2,proto=tcp.
6. Cliente: pasa a /etc/fstab con x-systemd.automount, nofail y timeouts.
7. Valida: simula downtime del servidor y confirma que el host sigue usable y arranca normalmente.

Paso a paso: implementar SSHFS sin sabotearte

1. Instala sshfs.
2. Confirma que SSH no interactivo funciona rápido (BatchMode).
3. Monta con reconnect y keepalives SSH.
4. Si es algo más que temporal: gestionalo con unidades systemd; añade automount si es necesario.
5. Sé conservador con el caché cuando existan múltiples escritores.

Checklist operacional: “este share nunca debe tumbar el host”

• Automount está habilitado para todos los montajes de red.
• Se han fijado timeouts en montajes (device timeout y mount timeout).
• Los servicios críticos no dependen hard de un montaje remoto salvo que estén diseñados para ello.
• Se aplica consistencia de UID/GID entre clientes.
• Tienes un procedimiento documentado para “desenganchar un montaje atascado”.
• Periodicamente pruebas fallos: reboot del servidor, caída de red, fallo de DNS.

Preguntas frecuentes

1) ¿Cuál es menos probable que se cuelgue: SSHFS o NFS?

SSHFS es menos probable que deje el kernel en reintentos indefinidos como puede hacerlo un montaje NFS hard, pero es más propenso a estancarse o desconectarse en redes inestables.
Para “no tumbar el host”, el ganador es NFS con systemd automount y timeouts.

2) ¿Debería usar montajes NFS hard o soft?

Por defecto, hard para corrección, pero combínalo con automount para que las caídas no congelen el arranque o el inicio de servicios.
Usa soft solo cuando la aplicación tolere errores de I/O y prefieras fallar sobre esperar.

3) ¿Por qué kill -9 no mata un proceso colgado en NFS?

Porque está atascado en sueño no interrumpible en el kernel esperando a que la E/S termine. La señal se anota pero no se entrega hasta que la syscall retorne.
La solución es restaurar servidor/red o desacoplar el montaje (umount lazy) para que el proceso pueda desenrollarse.

4) ¿Por qué SSHFS es tan lento en directorios con muchos ficheros pequeños?

Las operaciones de metadata requieren muchos idas y vueltas, y SSHFS añade sobrecarga de espacio de usuario y SFTP por cada una.
Para cargas de pequeños ficheros y directorios compartidos, NFS suele ser una mejor opción.

5) ¿NFSv4 requiere rpcbind?

NFSv4 está diseñado para ser más simple y típicamente usa el puerto 2049 sin la dependencia al portmapper que NFSv3 requería.
En la práctica, tu entorno puede ejecutar servicios RPC relacionados, pero la historia de firewall de NFSv4 es más limpia.

6) ¿Qué opciones de montaje son las más importantes para evitar “bloqueos aleatorios”?

Para ambos: lo más importante es systemd automount y timeouts.
Para SSHFS específicamente: ServerAliveInterval, ServerAliveCountMax y reconnect.
Para NFS: vers=4.2 explícito, proto=tcp y elegir hard vs soft con intención.

7) ¿Cómo desenmaraño un host donde todo lo que toca el montaje se cuelga?

Primero, deja de tocarlo. Luego restaura servidor/red si es posible. Si necesitas el host ya, usa umount -l en el punto de montaje.
Si hay SSHFS involucrado, para el proceso sshfs (unidad systemd) y luego desmonta lazy.

8) ¿SSHFS es “lo suficientemente seguro” comparado con NFS?

SSHFS se apoya en SSH, así que está cifrado y autenticado por defecto. NFS también puede ser seguro, pero hay que configurarlo—a menudo con Kerberos para auth fuerte.
Para redes no confiables, SSHFS es operativamente más simple. Para almacenamiento de producción en LAN confiable, NFS suele ser la herramienta más estable.

9) ¿Debería usar /etc/fstab o unidades systemd?

Para NFS, /etc/fstab con x-systemd.automount está perfectamente bien y es fácil de gestionar a escala.
Para SSHFS, las unidades systemd suelen ser más limpias porque es un daemon en espacio de usuario con necesidades de ciclo de vida.

10) ¿Y el bloqueo y la corrección para sistemas de build?

Si tu sistema de build depende de semánticas de locking y múltiples escritores, NFSv4 generalmente te da más opciones de corrección que SSHFS.
Pero la respuesta real es arquitectónica: evita usar un sistema de ficheros compartido como base de coordinación si puedes.

Siguientes pasos que puedes hacer hoy

Si solo haces tres cosas, haz estas:

1. Convierte montajes de red a systemd automount con timeouts explícitos. Esto por sí solo evita los bloqueos más humillantes.
2. Elige semánticas de fallo con intención: NFS hard para corrección, soft solo cuando errores sean aceptables. Deja de heredar defaults como política.
3. Ejecuta las tareas de diagnóstico en horas tranquilas: captura una línea base con nfsstat -m, confirma DNS, confirma accesibilidad de puertos y prueba una caída simulada.

Luego sé un poco implacable: si una aplicación no tolera rarezas de un sistema de ficheros remoto, no le des esa dependencia.
Sustituye “directorio compartido como capa de integración” por publicación de artefactos, caché local o un servicio adecuado. Tu yo de on-call te lo agradecerá.