OpenZFS 2.4.4 ya disponible: soporte Linux 7.2 y hardening de CAP_SYS_ADMIN

OpenZFS 2.4.4 es la actualización que necesitas aplicar si corres Linux 7.2, pero el verdadero motivo para prestarle atención no es el soporte de kernel: es el endurecimiento de CAP_SYS_ADMIN que llegó con el PR #18959 y que cambia qué puede hacer un container con privilegios sobre tu pool. Esta guía va más allá del anuncio oficial: explica qué cambia bajo el capó, cómo verificar si tu distro ya te ofreció el upgrade, cómo hacer rollback si rompe algo, y dónde están los caveats que el changelog no menciona.

El cambio de modelo de credenciales en ZFS

Durante años, OpenZFS asumió que cualquier credencial con CAP_SYS_ADMIN tenía autoridad plena sobre los objetos kernel-internos del módulo: sysctls, inyección de fallos con zinject, validación de credenciales NFSv4, control del MMP (Multi-Mutex Protection). El problema es que CAP_SYS_ADMIN es la capability comodín que Linux entrega a cualquier container con flags de runtime --privileged o con la capability explícita. Un container con CAP_SYS_ADMIN podía entonces tocar state global del host pool aunque “solo” tuviera acceso al mountpoint.

El PR #18959 introduce una nueva función crgetzone() que evalúa si la credencial pertenece a la zona inicial del namespace (lo que ZFS llama global zone, equivalente al init namespace de Linux). Si la credencial no pertenece a esa zona, las syscalls privilegiadas devuelven EACCES en lugar de ejecutarse. En deployments de Kubernetes con securityContext.capabilities.add: ["SYS_ADMIN"], esto cierra un vector real de ataque: el container ya no puede manipular el pool del host aunque el kernel se lo permita a nivel de capability.

Para el usuario doméstico con un NAS en casa, este cambio es invisible. Para quien corre OpenZFS como backing store de Postgres en Kubernetes, jails FreeBSD, o Podman con --privileged, es la diferencia entre un CVE latente y un ataque neutralizado.

Compatibilidad de kernel: la matriz que el README no aclara

El changelog dice “Linux 4.18 a 7.2”, pero en la práctica la matriz de compatibilidad tiene esquinas. Esta es la tabla que uso antes de recomendar un upgrade:

Rama OpenZFS	Kernels soportados oficialmente	Kernels con caveats conocidos	Kernels sin soporte
2.4.4 (estable actual)	6.1 LTS, 6.6 LTS, 6.12 LTS, 6.17, 6.18, 7.0, 7.1, 7.2	5.15 LTS (funciona pero sin fixes nuevos de VFS)	< 4.18, kernels -rc no testeados
2.3.9 (LTS anterior)	5.10 LTS, 5.15 LTS, 6.1 LTS, 6.6 LTS	6.12 LTS (sólo backport parcial)	7.x (necesita 2.4.x)
2.2.11 (legacy)	4.18, 5.4 LTS, 5.10 LTS	5.15 LTS sin RAID-Z expansion	6.x y superior

La rama 2.4 es la única que cubre Linux 7.x. Si tienes 6.18 con un pool grande (>100TB) y vas a moverte a 7.2, tienes que actualizar OpenZFS primero; actualizar el kernel sin actualizar ZFS te deja con un módulo que no compila.

Procedimiento de upgrade sin downtime

En un pool raíz o de producción, el upgrade sigue un patrón específico que evita pérdida de servicio:

# 1. Verificar el estado del pool antes de tocar nada
sudo zpool status -v
sudo zpool list -v
sudo zpool scrub  # Si hace falta, validar antes que no haya errores
# 2. Confirmar el módulo que está cargado
sudo modinfo zfs | grep -E '^(version|srcversion|depends)'
lsmod | grep zfs
# 3. Si usas DKMS (Ubuntu, Debian), el rebuild es automático al instalar:
sudo apt update && sudo apt install --only-upgrade openzfs-zfs-dkms
sudo modprobe -r zfs && sudo modprobe zfs
# 4. Si usas kABI-tracking kmods (RHEL/Fedora/Rocky via kmod-zfs),
# el paquete zfs-release entrega un kmod precompilado para tu kernel actual.
# NO requiere reinicio, pero sí un modprobe manual del nuevo módulo:
sudo dnf update zfs
sudo modprobe -r zfs && sudo modprobe zfs
# 5. Verificar post-upgrade
sudo zpool upgrade -v  # Muestra features habilitadas en cada pool
sudo zfs version        # Versión del userspace
sudo modinfo zfs | grep ^version

El paso crítico es el modprobe -r: hay que descargar el módulo viejo antes de cargar el nuevo. Si el módulo está en uso por un dataset montado, el modprobe -r falla con EBUSY. En ese caso, identificar qué proceso tiene archivos abiertos con lsof | grep /tu/pool y detenerlo antes de continuar.

Procedimiento de rollback

Si el upgrade rompe algo (kernel panic al cargar el módulo, comportamiento raro de un dataset, fallo de scrub), el rollback es directo pero requiere reboot en la mayoría de los casos:

# En RHEL/Fedora con kmod-zfs:
sudo dnf downgrade zfs kmod-zfs
sudo reboot  # El módulo viejo necesita kernel viejo si cambió kABI
# En Ubuntu con DKMS:
sudo apt install openzfs-zfs-dkms=2.4.3-1ubuntu1  # Pin a la versión anterior
sudo dkms remove zfs/2.4.4 --all
sudo dkms install zfs/2.4.3
sudo modprobe -r zfs && sudo modprobe zfs
# Compilación desde fuentes (rollback limpio):
cd ~/build/zfs
git checkout zfs-2.4.3
sudo make uninstall && sudo make install
sudo modprobe -r zfs && sudo modprobe zfs

El dato que casi nadie verifica: el formato on-disk de los pools NO cambia entre 2.4.x y 2.4.y. Los pools son compatibles hacia adelante y hacia atrás dentro de la misma major version. Si por algún motivo necesitas volver a 2.4.3 después de cargar features de pool en 2.4.4, puedes hacerlo con zpool upgrade -f en el sentido inverso, pero no uses un módulo de 2.4.x para leer un pool al que le activaste features de 2.5.x: eso corrompe datos.

Troubleshooting: los tres errores reales que vas a encontrar

Error 1: “module zfs: disagrees about version of symbol module_layout”

Significa que el módulo se compiló contra un kernel distinto al que está corriendo. En Ubuntu/Debian con DKMS esto pasa cuando instalas un kernel nuevo antes de que DKMS haya recompilado. Solución:

sudo dkms status  # Ver qué versiones están construidas
sudo dkms autoinstall
sudo modprobe zfs

Error 2: “cannot import pool: pool was previously in use from another system”

Si el pool está en un dispositivo compartido (iSCSI, NFS, multipath) o si el host anterior no hizo export limpio. La solución no es zpool import -f a ciegas; primero zpool status con la caché borrada y verificar si hay otro host activo:

sudo zpool import  # Lista pools disponibles para importar
sudo zpool import -d /dev/disk/by-id/  # Especificar paths por ID estable
sudo zpool import -f poolname  # Sólo si confirmas que no hay otro host

Error 3: “PANIC: zfs: freeing free block” en scrub

Es el síntoma clásico de un bug de 2.4.3 con el DDT pruning que el PR #18886 cierra. Si te pasó en 2.4.3 y no actualizaste, el scrub puede haber corrompido metadata. La recuperación:

sudo zpool scrub -e poolname  # Reclama espacio no usado
sudo zpool clear poolname     # Limpia el flag de error
# Si persiste, abrir issue con zdb -e poolname output

Decisión técnica: cuándo quedarte en 2.3.x

No todo el mundo debería saltar a 2.4.4. Hay tres escenarios donde quedarse en 2.3.9 tiene sentido:

• Pool con feature flags de 2.3 que no puedes revertir: si activaste zstd_compress en producción y tienes un cluster FreeBSD viejo que lee ese pool vía NFS, FreeBSD 13.3 con ZFS in-tree no entiende esa feature. El downgrade rompe el acceso del cluster.
• Hardware certificado con vendor que solo soporta 2.3: algunos appliances NAS (TrueNAS CORE forks, algunos QNAP con ZFS in-house) certifican contra una versión específica. Saltar puede invalidar soporte.
• Dependencias in-house de libzfs o libzfs_core con ABI estable: si tienes código C/C++ linkeado contra headers de ZFS, la API puede haber cambiado entre 2.3 y 2.4 en algunos puntos (especialmente nvpair). Compila y testea antes de promover.

Verificación final: el checklist de 5 minutos

Después del upgrade, este script te dice si todo está en orden:

#!/bin/bash
# zfs-health-check.sh — corre como root
set -e
echo "=== Versiones ==="
echo "Kernel: $(uname -r)"
echo "ZFS userspace: $(zfs version | head -1)"
echo "ZFS módulo: $(modinfo zfs 2>/dev/null | awk '/^version:/ {print $2}')"
echo
echo "=== Pools ==="
zpool list -H -o name,size,alloc,free,frag,health
echo
echo "=== Scrub reciente ==="
for pool in $(zpool list -H -o name); do
  echo "Pool: $pool"
  zpool status $pool | grep -E "(scan:|state:)"
done
echo
echo "=== Features activas ==="
zpool upgrade -v | head -20

Si el módulo y el userspace reportan versiones distintas, o si algún pool está en estado DEGRADED, no hay que entrar en pánico pero tampoco hay que considerar el upgrade terminado. La release está firmada por Tony Hutter (GPG key ID 6AD860EED4598027) y el código en github.com/openzfs/zfs/releases/tag/zfs-2.4.4.

Preguntas frecuentes

Lee también

• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Guía Definitiva: Configura AppArmor para Proteger tus Aplicaciones en Linux
• GPG para Sysadmins: Guía Definitiva para Cifrar Archivos en Linux
• Protege tu SSH: Configura 2FA con Google Authenticator, Guía Definitiva para Sysadmins