VPS convertido en sistema de archivos de solo lectura (2026): solución de read-only file system, fsck y emergency mode

Primero mira el estado de montaje de la partición raíz:

findmnt /
mount | grep ' on / '

Si ves algo como:

/ rw,relatime,...

significa que la partición raíz sigue en lectura-escritura. En este caso, no poder escribir archivos puede deberse a disco lleno, inodos agotados, permisos de directorio, cuotas o problemas de la propia aplicación.

Si ves:

/ ro,relatime,...

Aquí ro significa read-only, y la partición raíz ya se ha montado en solo lectura. En este momento, no trates el problema como un error de permisos ordinario.

También revisa espacio e inodos:

df -h
df -i

Si el espacio está lleno, puedes leer primero: ¿Qué hacer cuando el disco del VPS está lleno? Limpieza de disco + ampliación. Si todavía hay espacio pero los inodos están agotados, lee esto: El VPS muestra espacio en disco disponible pero no puede escribir archivos: diagnóstico de agotamiento de inodos.

Cuando el sistema de archivos se vuelve de solo lectura, los registros de la aplicación a menudo solo te dicen "escritura fallida"; la causa real está en los registros del kernel.

dmesg -T | tail -n 100
journalctl -k --since "2 hours ago"

Busca estas palabras clave:

EXT4-fs error
Buffer I/O error
blk_update_request
I/O error
Remounting filesystem read-only
XFS ... metadata I/O error

Si aparece Remounting filesystem read-only, significa que el kernel detectó una anomalía en el sistema de archivos o en el dispositivo de bloque y lo volvió a montar en solo lectura de forma proactiva.

Si no estás familiarizado con el diagnóstico de registros, puedes consultar primero: Cómo leer los registros del VPS: journalctl, systemctl, Nginx, registros de aplicaciones.

Muchos tutoriales te darán directamente:

sudo mount -o remount,rw /

Este comando no es inutilizable, pero no puede ser el primer paso.

Si solo es una anomalía temporal de parámetros de montaje, el remount puede restaurar la escritura; pero si el disco subyacente o el sistema de archivos ya ha reportado errores, forzar la escritura puede ampliar la corrupción. Un orden más seguro es:

1. Revisa si dmesg / journalctl -k tiene errores de E/S o del sistema de archivos.
2. Haz primero una copia de seguridad de los datos importantes que aún se puedan leer.
3. Determina si necesitas entrar en modo de rescate para ejecutar fsck.
4. Monta en lectura-escritura después de la reparación.

Solo cuando los registros no muestran errores evidentes de disco/sistema de archivos y confirmas que el riesgo es controlable, intenta:

sudo mount -o remount,rw /

Si el comando falla, anota el error y no lo ejecutes repetidamente.

A veces el estado de solo lectura es en realidad una oportunidad: el sistema temporalmente no puede escribir, pero aún puede leer. Saca primero los datos clave.

Prioriza hacer copia de seguridad de:

• Volcados de bases de datos o directorios de datos
• /var/www, directorios de carga de la aplicación
• /etc/nginx, /etc/systemd/system, configuraciones de la aplicación
• .env, claves, certificados
• Registros recientes y capturas de pantalla del diagnóstico

Si la máquina aún puede conectarse a la red, puedes extraerlos con rsync:

rsync -aHAX --numeric-ids /var/www/ user@backup-server:/backup/vps-www/

Si la red es inestable, primero comprime los directorios clave en otro disco de datos montado correctamente, o usa instantáneas del panel/instantáneas del disco en la nube. Para estrategias de copia de seguridad, puedes consultar: Soluciones de copia de seguridad automática para VPS.

Una causa muy común de entrar en emergency mode tras reiniciar es un /etc/fstab mal configurado:

• Se escribió un UUID inexistente.
• Se montó un disco en la nube que ya ha sido eliminado.
• El tipo de sistema de archivos es incorrecto.
• Falló el montaje de un disco de red o almacenamiento de objetos, pero no hay nofail.
• Tras añadir manualmente un disco de datos, el orden de arranque es inestable.

Ver fstab:

cat /etc/fstab
blkid
lsblk -f

Si encuentras que el UUID de una partición no raíz no existe, puedes comentar temporalmente esa línea y luego reiniciar para verificar.

Para discos de datos no críticos, se recomienda añadir nofail para evitar que un fallo de montaje de un disco adicional bloquee todo el VPS en emergency mode:

UUID=xxxx /data ext4 defaults,nofail 0 2

No añadas nofail a la partición raíz sin cuidado. Si la partición raíz no se puede montar, de todos modos debería detenerse y manejarse.

Si la partición raíz ya ha reportado errores de ext4, normalmente se necesita fsck. Pero ejecutar fsck directamente en una partición raíz montada es una operación peligrosa.

Un enfoque más seguro:

1. Entra en el modo de rescate / modo de recuperación proporcionado por tu proveedor de VPS.
2. Encuentra el nombre del dispositivo de la partición raíz.
3. Confirma que no está montada.
4. Ejecuta fsck.

Ver particiones:

lsblk -f
blkid

Suponiendo que la partición raíz es /dev/vda1:

sudo fsck -f /dev/vda1

Si es XFS, no puedes usar el método de reparación fsck de ext4:

sudo xfs_repair /dev/vda1

Nota: en los entornos de rescate de diferentes proveedores, el nombre del dispositivo puede cambiar de /dev/vda1 a /dev/sda1 o /dev/nvme0n1p1. Siempre guíate por lsblk -f, y no copies el nombre de dispositivo de otra persona.

Si los registros contienen una gran cantidad de errores de E/S, por ejemplo:

Buffer I/O error on dev vda
blk_update_request: I/O error

Esto no es necesariamente una configuración incorrecta en tu sistema; también podría ser:

• Anomalía subyacente del disco en la nube
• Inestabilidad del almacenamiento del host
• Fallo del nodo del VPS
• Sobreventa que causa anomalías de E/S prolongadas
• Disco en la nube migrado o limitado en velocidad por el proveedor

En este caso, conserva los registros y abre un ticket lo antes posible. En el ticket, no escribas solo "la máquina está rota"; es mejor incluir:

dmesg -T | tail -n 100
journalctl -k --since "6 hours ago"
lsblk -f
findmnt /

Si sospechas de contención de recursos de vecinos o inestabilidad del disco, puedes comparar con: Cómo juzgar la sobreventa de VPS: robo de CPU, inestabilidad del disco, vecinos acaparando recursos.

Después de completar fsck o xfs_repair, monta y verifica primero:

sudo mount /dev/vda1 /mnt
ls /mnt

Fíjate en:

• Si /mnt/lost+found tiene una gran cantidad de archivos
• Si el directorio de la base de datos está completo
• Si el directorio de carga de la aplicación está completo
• Si /etc/fstab se ha corregido
• Si todavía hay nuevos errores de E/S en los registros

Si puede arrancar normalmente, tampoco devuelvas el tráfico de inmediato. Revisa primero los servicios:

systemctl --failed
journalctl -p err -b

Ten especial cuidado con los servicios de base de datos. Si servicios como MySQL, PostgreSQL y Redis fueron interrumpidos a la fuerza durante la anomalía del sistema de archivos, también pueden necesitar sus propias verificaciones de consistencia de datos.

En las siguientes situaciones, no se recomienda seguir forzando la reparación en el disco original:

• dmesg muestra errores de E/S de forma continua.
• Vuelve a ponerse en solo lectura poco después de la reparación con fsck.
• Los archivos clave de la base de datos están corruptos y no hay verificación fiable.
• El proveedor confirma una anomalía en el nodo de almacenamiento.
• Esta máquina ya ha entrado en emergency mode varias veces.

En este punto, una ruta más segura es:

1. Restaurar desde instantánea o copia de seguridad a un nuevo VPS.
2. Verificar los datos del negocio.
3. Cambiar el DNS o la entrada del proxy inverso.
4. Mantener la máquina antigua en estado de solo lectura para recuperar datos adicionales.

Para ideas de migración, puedes consultar: Guía de migración de VPS: cómo reducir el tiempo de inactividad al cambiar de proveedor/centro de datos.

Al encontrar read-only file system o emergency mode, procede en este orden:

1. findmnt / revisa si la partición raíz está ro.
2. df -h y df -i para descartar espacio lleno y agotamiento de inodos.
3. dmesg -T / journalctl -k para encontrar errores del sistema de archivos y de E/S.
4. Haz copia de seguridad de los directorios clave primero cuando los datos sean legibles.
5. Revisa si /etc/fstab, blkid, lsblk -f coinciden.
6. No ejecutes fsck directamente en una partición raíz montada.
7. Entra en modo de rescate y ejecuta fsck o xfs_repair en la partición no montada.
8. Tras la reparación, revisa systemctl --failed y los registros de errores.
9. Si los errores de E/S persisten, prioriza la migración; no sigas apostando por el disco original.

Que un VPS se convierta en un sistema de archivos de solo lectura no es un simple "permisos insuficientes". A menudo es el sistema protegiendo los datos: o el disco/sistema de archivos ha fallado, o la configuración de montaje de arranque es inconsistente, o el disco en la nube subyacente ya se ha vuelto inestable.

El orden correcto de manejo es: mira primero los registros y el estado de montaje, haz copia de seguridad primero si es legible, luego corrige fstab o entra en modo de rescate para hacer una verificación del sistema de archivos. Recuperarse es bueno, pero mientras los errores de E/S sigan apareciendo, no sigas apostando tu negocio por el disco original; migra a una nueva máquina lo antes posible.