Solución al Error «No space left on device» en Linux Cuando Queda Espacio Libre

Introducción al Paradójico Error ENOSPC en Linux

Uno de los problemas más desconcertantes para administradores de sistemas y desarrolladores en entornos Linux ocurre cuando una aplicación, base de datos o comando del sistema operativo falla abruptamente arrojando el mensaje No space left on device (código de error de kernel ENOSPC), mientras que al ejecutar el comando estándar df -h se observa con claridad que la partición afectada dispone de decenas o cientos de gigabytes libres.

Este fallo detiene servicios de producción críticos como bases de datos MySQL/PostgreSQL, servidores web Nginx o Apache, y pipelines de integración continua. Lejos de ser un fallo de hardware en la unidad de almacenamiento, este comportamiento se debe a las particularidades arquitectónicas con las que los sistemas de archivos de Linux (tales como ext4, XFS o Btrfs) gestionan el espacio físico, los metadatos y los descriptores de archivos en memoria. En esta guía técnica exhaustiva analizaremos las causas profundas de esta anomalía y abordaremos las soluciones operativas definitivas paso a paso.

Causas Técnicas: ¿Por Qué Falla la Asignación de Bloques?

En el estándar POSIX y el kernel de Linux, el almacenamiento no solo se mide en bytes o bloques de datos, sino también mediante estructuras de control e índices. Existen cuatro escenarios fundamentales que desencadenan este error:

• Agotamiento de Inodos (Inode Exhaustion): En sistemas de archivos tradicionales como ext4, la cantidad total de inodos (estructuras de datos que representan cada archivo, directorio o enlace simbólico) se fija durante el formateo. Si un sistema genera millones de archivos diminutos (por ejemplo, sesiones PHP huérfanas, archivos temporales o colas de correo en spool), se pueden agotar el 100% de los inodos disponibles antes de consumir siquiera el 10% de la capacidad en gigabytes.
• Archivos Eliminados Retenidos en Memoria (Unlinked Open File Descriptors): Cuando un proceso mantiene abierto un archivo (como un log de gran tamaño) y dicho archivo es eliminado con rm, el enlace en el directorio desaparece, pero el kernel no libera los bloques de disco hasta que el proceso que retiene el descriptor de archivo (file descriptor) finaliza o cierra el flujo. Mientras tanto, du no verá el archivo, pero df computará el espacio como ocupado y el kernel denegará nuevas escrituras.
• Bloques Reservados para el Superusuario: Por defecto, particiones ext3/ext4 reservan un 5% de su capacidad total exclusivamente para el usuario root para evitar la fragmentación crítica y permitir el arranque del sistema en emergencias. Si un usuario no privilegiado intenta escribir y la partición supera el 95% de uso, recibirá el error a pesar de que el disco aún conserve espacio físico libre.
• Puntos de Montaje Ocultos (Overmounting): Si se monta un sistema de archivos secundario sobre un directorio que ya contenía datos, esos archivos quedan ocultos para el usuario pero continúan consumiendo bloques en la partición base subyacente.

Método 1: Diagnóstico y Mitigación del Agotamiento de Inodos

El primer paso técnico consiste en verificar si la limitación reside en la tabla de metadatos del sistema de archivos. Para comprobar el uso de inodos en todas las particiones montadas, ejecuta:

df -i

Observa la columna IUse%. Si observas un valor del 99% o 100% en alguna partición, has confirmado la causa. Para localizar qué directorio específico alberga la anomalía de millones de archivos, ejecuta el siguiente script directo en tu terminal sobre la ruta afectada (por ejemplo, /var):

for d in /var/*; do echo -n "$d: "; find "$d" -xdev | wc -l; done | sort -k2 -nr

Solución: Eliminación Masiva Sin Desbordar el Argument List

Cuando un directorio acumula cientos de miles de archivos, intentar eliminarlos mediante rm -rf /ruta/* resultará en el fallo clásico bash: /bin/rm: Argument list too long. La forma correcta y eficiente de purgar estos archivos a nivel de kernel es combinando find con -delete o canalizando hacia xargs:

find /var/spool/clientmqueue -type f -delete

O alternativamente utilizando procesamiento en paralelo por lotes:

find /var/lib/php/sessions -type f -name "sess_*" -print0 | xargs -0 -P 4 rm -f

Una vez completada la purga, vuelve a verificar el estado con df -i para constatar que el porcentaje de uso de inodos ha vuelto a niveles normales.

Método 2: Liberar Espacio de Archivos Eliminados pero Retenidos por Procesos

Si tanto df -h como df -i muestran discrepancias y sospechas de procesos activos reteniendo descriptores huérfanos, la herramienta fundamental de diagnóstico es lsof.

Paso 1: Identificar Descriptores Abiertos No Enlazados

Ejecuta el siguiente comando con privilegios de administrador para listar archivos marcados como deleted pero que continúan asignados a un proceso activo:

lsof +L1

O filtra específicamente los archivos más voluminosos mediante:

lsof / | grep -i delete | sort -k7 -nr | head -n 10

El resultado mostrará el PID del proceso, el nombre del binario (por ejemplo, java, mysqld o rsyslogd), el descriptor de archivo (FD) y el tamaño real en bytes que el kernel mantiene bloqueado.

Paso 2: Liberar el Espacio Sin Reiniciar el Servicio Crítico

Si el proceso afectado corresponde a una base de datos o servicio crítico de producción que no puede reiniciarse de inmediato, puedes truncar el archivo directamente accediendo al subsistema /proc mediante su PID y número de descriptor:

echo "" > /proc/<PID>/fd/<FD_NUMERO>

Por ejemplo, si el proceso con PID 4521 mantiene abierto un archivo de log gigante eliminado en su descriptor 3, ejecuta:

truncate -s 0 /proc/4521/fd/3

El kernel truncará inmediatamente la longitud del archivo a cero bytes, liberando todos los bloques de datos asociados en el disco sin interrumpir la ejecución del proceso.

Método 3: Ajuste de Bloques Reservados en ext4 con tune2fs

En volúmenes de almacenamiento dedicados a almacenamiento secundario, volcados de backups o particiones de datos como /data o /srv, la reserva predeterminada del 5% del tamaño total de la partición para el superusuario suele ser innecesaria y provoca fallos de escritura prematuros a servicios que corren bajo usuarios dedicados (como postgres o www-data).

Para comprobar la cantidad de bloques reservados en un dispositivo montado, ejecuta:

tune2fs -l /dev/sda1 | grep "Reserved block count"

Para reducir este margen del 5% original a un 1% (o incluso 0% en discos dedicados exclusivamente a datos que no contienen rutas críticas del sistema operativo), utiliza:

sudo tune2fs -m 1 /dev/sda1

En un disco de 2 Terabytes, este ajuste libera de forma instantánea aproximadamente 80 Gigabytes de espacio inmediatamente utilizable por cualquier usuario o servicio no privilegiado.

Método 4: Descubrimiento de Directorios Sobremontados

Cuando un administrador monta una partición secundaria sobre un directorio que ya contenía datos, esos archivos quedan eclipsados. Las herramientas habituales de escaneo como du solo iterarán sobre los archivos del nuevo punto de montaje, omitiendo los datos atrapados debajo.

Para inspeccionar el contenido oculto en el directorio base, realiza un montaje de enlace (bind mount) de la partición raíz en una ubicación temporal alternativa:

mkdir /mnt/temp_root
sudo mount --bind / /mnt/temp_root

Ahora inspecciona el directorio que actúa como punto de montaje sospechoso a través del acceso temporal:

du -sh /mnt/temp_root/var/log/*

Si detectas archivos obsoletos que fueron cubiertos por el nuevo montaje, puedes eliminarlos directamente desde /mnt/temp_root/. Una vez finalizada la limpieza, desmonta la interfaz temporal:

sudo umount /mnt/temp_root && rmdir /mnt/temp_root

Buenas Prácticas y Prevención Proactiva

Para evitar que el error ENOSPC vuelva a paralizar tus servidores de producción, implementa las siguientes directrices:

1. Configurar Logrotate Riguroso: Asegúrate de que todos los logs generados por aplicaciones tengan políticas de rotación diaria con compresión (compress) y directiva copytruncate si los procesos no admiten señales de reapertura de descriptores.
2. Monitoreo de Inodos en Prometheus o Zabbix: Configura alertas tempranas cuando el uso de inodos (métrica node_filesystem_files_free en Node Exporter) caiga por debajo del 15%, no limitándote únicamente al monitoreo del tamaño en gigabytes.
3. Gestión de Tareas Cron para Archivos Temporales: Implementa tareas programadas para limpiar sockets caducados, colas de impresión y archivos temporales huérfanos generados en /tmp mediante utilidades como systemd-tmpfiles.