Technology · GUÍA PRÁCTICA
¿Linux dice “Read-only file system”? Pruebe primero el mount, namespace y dispositivo
Mapee la ruta al mount más profundo, conserve el primer error del kernel y separe política, namespace, protección del medio y daño antes de remontar o reparar.
EROFS es un estado de mount o filesystem, no un permiso Unix normal. El proceso puede ver un árbol de mounts distinto al shell administrador.
Fije ruta, PID, hora y error; identifique el mount profundo y conserve evidencia del kernel y dispositivo antes de reparar la rama probada.
Fije la frontera exacta del fallo
Registre ruta absoluta, PID, errno, hora, operación, identidad y contexto de contenedor o servicio; detenga reintentos que borren evidencia.
En el contexto fallido use findmnt -T y /proc/PID/mountinfo para hallar el target más profundo y compárelo con el shell administrador.
Separe política de remount por error
Confirme si ro está en VFS, filesystem o ambos; revise fstab, unit, bind, image, overlay y cloud volume config.
Conserve journalctl -k o dmesg alrededor del primer momento. ext4 errors=remount-ro define el cambio a solo lectura tras un error.
Pruebe el owner y el alcance
Mapee SOURCE, UUID, device-mapper, RAID, export de red, loop image o volumen cloud, y compruebe el block device.
Si solo un namespace/bind es readonly, repare esa política; si lo es el superblock/device, todos los paths respaldados están afectados.
Repare solo la rama probada
Para política cambie la configuración fuente; para error de filesystem/media detenga escritores, conserve diagnósticos, desmonte o entre en recovery y siga el procedimiento oficial.
No ejecute fsck sobre un filesystem writable montado, no fuerce rw repetidamente ni borre logs por conjetura.
Acepte en el namespace original
Vuelva al service/container/PID original, confirme flags del path exacto y ausencia de nuevos errores de kernel o device.
Cree un archivo único, escriba, fsync, lea, compare y elimine; observe una operación normal. Si vuelve EROFS, pare y escale.
