Skip to content

NAS reboot & NFS (nfsd) deadlock recovery

TerraMaster F4-423 (192.168.0.20, renombrado desde .237 en la renumeración IP de 2026-07-31), NFS server for VM 208's media stack.

Actualizado 2026-07-26 con la causa raíz ya identificada. Ver el análisis completo en nfsd-deadlock-2026-07-26. Lo que este runbook decía antes («kernel-level I/O stall») era incorrecto.

Síntoma: avalancha de alertas, contenedores caídos, load del NAS alto

Avalancha de media_container_missing en el 208 con el 208 sano = hilos nfsd del NAS muertos en D-state. Sin riesgo de datos (el RAID está bien).

Diagnóstico (en el NAS):

ps -eo stat,comm | grep nfsd | grep -c D   # >0 = hilos perdidos
ss -tln | grep 2049                        # Recv-Q alta = encolando sin aceptar
cat /root/nas-hang-forensics.log | tail -50   # pilas de kernel del incidente

Firma en métricas: load1 clavado en un entero plano (1 por hilo perdido), con disco, red y nfsd a CERO y procs_blocked=0. procs_blocked sólo cuenta iowait; el load cuenta toda tarea en D → si divergen, es deadlock de cerrojos del kernel, no saturación de E/S. El NAS se cuelga con el disco parado.

⚠️ GOTCHA que cuesta horas: en este NAS sudo te DEGRADA

El shell de monxas por SSH ya es uid 0 real. sudo cambia a uid 9999 sandboxeado.

sudo btrfs subvolume list /Volume1   # Permission denied
btrfs subvolume list /Volume1        # funciona
sudo cat /proc/1/stack               # Permission denied
cat /proc/1/stack                    # funciona

Nunca uses sudo en el NAS. (Por eso reboot/systemctl reboot fallan con polkit: el que los ejecuta es el uid degradado.)

Cura: reiniciar el NAS

Un D-state no se mata ni con kill -9. La única cura es reiniciar.

Automático (desde 2026-07-26): nas-volume-selfheal.sh lo hace solo si se pierde ≥50 % de los hilos nfsd sostenido 10 min. Con 1-2 hilos perdidos sólo registra en /root/selfheal-fired.log — el NFS sigue sirviendo y reiniciar sería peor.

Manual, botón rojo (probado en producción 2026-07-26):

ssh [email protected] '/home/monxas/scripts/nas-red-button.sh reboot'

Escala solo: reboot limpio → sysrq-b → aviso para botón físico. Funciona a través de una sesión NFS deadlockeada porque su clave vive en /etc/ssh/authorized_keys.d/ (rootfs, md9), no en ~/.ssh (que está en el volumen).

Panel TOS (:8181 o :5443 → Restart, NUNCA Shutdown) como alternativa. Ojo: si el deadlock se lleva el backend web, el panel sirve sólo la página estática y no sirve.

Botón físico cuando todo lo anterior falla (pasó el 2026-07-26 por la mañana).

Tras volver el NAS

nfs-health-monitor en el 208 recupera solo. Desde 2026-07-26 incluye reconciliación: recuerda qué contenedores NFS estaban vivos antes de la avería y los levanta al volver el NFS. En operación normal no toca nada (si no, se pelearía con Sablier, que para trip-planner a propósito).

Bind mounts stale: al remontarse el NFS, los contenedores que siguieron "Up" apuntan al directorio vacío previo → Sonarr dice "will exceed available disk space" con TB libres. rebind_nfs_containers() lo arregla en la recuperación. Manual: ~/scripts/nfs-health-monitor.sh rebind.

Verificar: docker exec -u 1000 jellyfin ls /data/ (no debe dar permission denied) y Prometheus firing=0.

Endurecimiento — estado

  • ✅ Auto-reboot por deadlock de nfsd (2026-07-26). Antes el vigilante sólo miraba si stat /Volume1 respondía, y en este fallo el volumen está sano → nunca disparaba. Confirmado disparando de verdad el 3-ago (07:50) y el 4-ago (06:59) — node_boot_time_seconds en Prometheus, no sólo lógica probada en simulacro.
  • ✅ Reconciliación de contenedores (2026-07-26).
  • ✅ Captura forense persistente (/root/nas-hang-forensics.log) — /var/log del NAS es tmpfs y se borraba en cada reinicio, que es por qué esto tardó semanas en diagnosticarse.
  • ✅ NFSv3 en pmx-50/51 y VM 208, CIFS en HA (2026-08-04) — los 4 clientes NFS conocidos están ahora fuera de NFSv4, sin esperar al parche de kernel. Detalle completo y procedimientos exactos en nfsd-deadlock-2026-07-26 § actualización 2026-08-04.
  • ✅ Alerta temprana antes del auto-reboot (2026-08-04): métrica nfsd_threads_dstate{host="tnas"} + reglas nas_nfsd_dstate_degraded/_critical en Prometheus, misma sección de arriba. Avisa por Telegram antes de que dispare el auto-reboot del vigilante, no lo sustituye.
  • ⬜ Arreglo de fondo: kernel ≥6.1.129 (donde upstream corrige el deadlock; ver Debian #1071562). El NAS sigue en 6.1.120. No es necesariamente TOS 7 — su kernel exacto en el release final no está confirmado, puede seguir en rama 6.1.x, y hay riesgo reportado de que la conversión de permisos post-update rompa el export NFS de este NAS. Sin prisa: vigilar changelog de TOS 6.0.8xx+ para un bump de kernel más pequeño.
  • ⬜ Subir el pool de hilos nfsd (8→32) no es posible sin parchear binarios propietarios de TOS (allconf regenera el conteo hardcodeado en cada arranque del servicio). Descartado; impacto bajo ahora que ningún cliente propio toca NFSv4.
  • ⬜ pmx-50 también se resetea en cascada cuando el NAS entra en deadlock (visto el 4-ago, watchdog hardware de la HA de Proxmox armado a 10s) — mitigado indirectamente al quitar los 4 clientes de NFSv4, pero el mecanismo exacto no está confirmado con un log literal. Ver la misma sección de arriba.
  • ⬜ Enchufe inteligente como corte de corriente de último recurso.