Al intentar guardar un archivo o actualizar un servicio en SUSE Linux Enterprise Server (SLES), Linux responde con el mensaje "Sistema de archivos de solo lectura". Este mensaje puede indicar que el montaje se configuró deliberadamente como de solo lectura, que se inició una instantánea de Snapper de solo lectura o que Btrfs detectó un problema y dejó de aceptar escrituras para proteger el volumen. Estas causas requieren soluciones diferentes. Comience por identificar el sistema de archivos y el montaje involucrados; no fuerce el remontaje ni ejecute un comando de reparación antes de revisar los registros del kernel y proteger los datos importantes.
Qué significa el error
Btrfs es un sistema de archivos Linux de copia en escritura que se utiliza por defecto para el sistema de archivos raíz de SLES en muchas instalaciones estándar. Un subvolumen Btrfs es una parte de un sistema de archivos que se puede montar de forma independiente; una instantánea es una copia puntual de un subvolumen que comparte bloques de datos sin cambios. Snapper y el menú de arranque de SLES pueden usar instantáneas para recuperarse de cambios en el sistema. Al arrancar una instantánea, las partes incluidas se montan intencionadamente en modo de solo lectura. Por separado, Btrfs puede cambiar al modo de solo lectura tras detectar ciertos errores estructurales para evitar escrituras adicionales. SUSE documenta el comportamiento de las instantáneas en su guía de Snapper para SLES 15 SP7 ; el proyecto Btrfs explica que las comprobaciones estructurales del sistema de archivos pueden cambiar un volumen al modo de solo lectura para evitar daños adicionales en su documentación del verificador de árbol . Las etiquetas exactas del menú y las opciones de recuperación disponibles pueden variar según el Service Pack de SLES y la configuración de almacenamiento.
Un problema de permisos es diferente. El mensaje "Permiso denegado" suele indicar problemas de propiedad o control de acceso; "Sistema de archivos de solo lectura" (que a menudo se muestra como EROFS) indica el estado del sistema de archivos o subvolumen. Cambiar los permisos de archivo con chmodno hará que un montaje de solo lectura sea editable.
Antes de cambiar nada
Si se trata de un servidor de producción, un volumen de base de datos o la única copia de datos importantes, contacte con el administrador del sistema y confirme la copia de seguridad antes de intentar la recuperación. Si el sistema aún es legible, copie los archivos más importantes a un almacenamiento independiente en buen estado, si puede hacerlo sin sobrecargar un dispositivo con fallos. Es posible que Btrfs solo conserve en memoria los cambios recientes de metadatos tras un error crítico; al desmontar o reiniciar el sistema, se pueden perder esos cambios no confirmados. Si los registros mencionan errores de E/S, dispositivos que desaparecen o reinicios repetidos, priorice el estado del almacenamiento y la protección de datos sobre la restauración de las escrituras.
No lo ejecute btrfs check --repaircomo primer paso rutinario. El proyecto Btrfs advierte que el modo de reparación puede causar daños y no puede solucionar todos los tipos de corrupción. Tampoco fuerce repetidamente el remontaje de lectura y escritura: podría fallar inmediatamente si el kernel ha protegido el sistema de archivos por algún motivo.
Paso 1: Identificar la pieza afectada
Utilice la ruta donde falló la escritura. Por ejemplo, si un servicio no puede escribir en /srv/app, inspeccione esa ruta en lugar de asumir que el problema reside en el sistema de archivos raíz:
findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS
Reemplace /srv/appcon el archivo o directorio afectado. Verifique la salida para el origen Btrfs, el destino de montaje y una opción de roo rw. El destino puede ser /, un montaje de datos independiente o un subvolumen. Anote el origen y el destino antes de continuar. Si el comando informa otro tipo de sistema de archivos, los pasos específicos de Btrfs no se aplican a esa ruta.
Compruebe los mensajes del kernel del arranque actual para averiguar por qué el sistema de archivos se ha vuelto de solo lectura:
sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'
Busque errores de Btrfs o mensajes de "solo lectura forzada", errores de suma de comprobación o de árbol, fallos de E/S del dispositivo y desconexiones del dispositivo. Una línea de registro es una pista, no un diagnóstico completo. Guarde los mensajes y las marcas de tiempo relevantes antes de reiniciar, ya que los registros pueden ser útiles para el equipo de soporte de almacenamiento o hardware.
Paso 2: Compruebe si existe una instantánea intencional de solo lectura.
Si el servidor se inició desde una instantánea de arranque en GRUB, los archivos incluidos en dicha instantánea son de solo lectura por diseño. Este es un entorno de recuperación para comprobar un estado anterior del sistema; no es automáticamente el sistema restaurado permanentemente. Confirme la entrada de arranque con el administrador, luego reinicie y seleccione la entrada SLES predeterminada normal si el arranque desde la instantánea fue accidental. SUSE documenta que el arranque desde una instantánea monta las partes del sistema de archivos incluidas en modo de solo lectura y describe el procedimiento de reversión independiente en su guía de recuperación de Snapper para SLES 15 SP7 .
Una instantánea en particular puede ser de solo lectura incluso cuando el sistema de archivos principal está montado en modo lectura/escritura. Si trabaja intencionalmente con una instantánea, inspecciónela sin modificarla:
sudo btrfs property get -t subvol /path/to/subvolume ro
Reemplace la ruta con la ruta de montaje del subvolumen. El resultado ro=trueconfirma que la propiedad del subvolumen es de solo lectura; la documentación de referencia de propiedades de Btrfs indica esta bandera. No cambie simplemente a lectura y escritura una instantánea de copia de seguridad administrada o recibida por Snapper: el estado de solo lectura puede formar parte de las suposiciones de reversión o copia de seguridad incremental. Utilice un flujo de trabajo de Snapper compatible o cree un subvolumen de escritura independiente cuando esa sea la tarea prevista.
Paso 3: Revise la configuración de montaje y el estado del almacenamiento.
Si findmntlos informes roy los registros no muestran errores de Btrfs o E/S, inspeccione la entrada de montaje correspondiente en /etc/fstab. Es posible que un montaje se haya configurado deliberadamente como de solo lectura para la recuperación, una imagen del dispositivo o una política de protección de datos. Cambie la configuración solo después de confirmar el estado previsto con el propietario del servicio. Compruebe también si el sistema utiliza una implementación transaccional o de raíz de solo lectura: SLES documenta dichas configuraciones y su flujo de trabajo de mantenimiento en su guía de actualizaciones transaccionales . Si la entrada está explícitamente destinada a ser escribible, el dispositivo está en buen estado y la ruta no es una instantánea de solo lectura, un administrador puede intentar un remontaje temporal:
sudo mount -o remount,rw /mountpoint
Reemplazar /mountpointcon el destino exacto que se muestra findmnt. Esto no diagnostica ni repara la corrupción. Si falla, devuelve un error o los registros del kernel muestran problemas de almacenamiento, deténgase y pase a la planificación de recuperación en lugar de volver a intentarlo con más opciones.
Para detectar posibles problemas de capacidad, revise la asignación de Btrfs y el estado del dispositivo:
sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint
SUSE señala que los resúmenes de espacio libre en disco pueden ser engañosos en Btrfs, ya que los datos y los metadatos se asignan por separado. Las instantáneas de Snapper también pueden conservar un espacio considerable. Sin embargo, el mensaje "No queda espacio en el dispositivo" no es idéntico a un error de solo lectura de Btrfs; identifique qué mensaje recibió realmente la aplicación. No elimine instantáneas solo para probar una teoría. Confirme primero su contenido y siga la política de retención aplicable. Consulte la guía de solución de problemas del sistema de archivos de SLES 15 SP7 .
Paso 4: Decida si el sistema de archivos necesita recuperación.
Si aparecen errores de Btrfs en el registro del kernel, falta el dispositivo o se rechaza el remontaje, conserve los registros y realice una copia de seguridad verificada o una instantánea a nivel de almacenamiento antes de realizar las reparaciones. Para un volumen de datos que no sea la raíz, planifique una ventana de mantenimiento y desmóntelo antes de las comprobaciones sin conexión. Para el sistema de archivos raíz, utilice el medio de instalación o de recuperación de SUSE y siga el procedimiento correspondiente a la versión exacta de SLES y la firma de error. No intente adivinar el nombre del dispositivo: un sistema de archivos Btrfs puede abarcar varios dispositivos, por lo que primero debe establecer todos los miembros y los identificadores de montaje o de dispositivo correctos.
La guía de administración de SUSE SLES 15 SP7 incluye una sección específica para particiones raíz Btrfs que no se pueden montar. En ella se describen las opciones de recuperación para este fallo de arranque. Estas instrucciones no implican que se deba borrar el registro de todos los sistemas de archivos de solo lectura montados. El manual de btrfs-rescue explica que esto btrfs rescue zero-logse aplica a ciertos fallos de reproducción de registros durante el montaje y puede descartar los cambios realizados desde la última transacción confirmada. Úselo únicamente cuando el error registrado coincida con el caso documentado y el plan de recuperación contemple la posible pérdida de datos.
btrfs checkPor defecto, se ejecuta en modo de solo lectura en un sistema de archivos desmontado. Manténgalo así para la evaluación inicial y comparta su resultado con el soporte de SUSE o un especialista en Btrfs. El manual de btrfs-check advierte explícitamente sobre su uso --repairsin el asesoramiento de un usuario o desarrollador experimentado. Nunca ejecute un verificador sin conexión en un sistema de archivos montado y en constante cambio.
Paso 5: Verificar la recuperación
Una vez corregida la causa, reinicie el sistema solo cuando lo indique el plan de recuperación. A continuación, vuelva a intentarlo findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONSy confirme que el punto de montaje previsto permite la lectura y escritura. Compruebe el registro del kernel en busca de errores recientes de Btrfs o de E/S. Por último, verifique que el servicio o la aplicación afectados puedan funcionar con normalidad y confirme que la copia de seguridad sigue disponible. Un remontaje exitoso por sí solo no garantiza que el almacenamiento esté en buen estado.
Si el sistema de archivos vuelve al modo de solo lectura, el dispositivo se desconecta o persisten los errores, detenga las escrituras y proceda con los registros guardados, findmntla salida, la lista de dispositivos Btrfs, el nivel del Service Pack de SLES y los detalles del controlador de almacenamiento. Esta información ayuda a distinguir una instantánea o una opción de montaje intencionada de daños en el medio, la conexión, el controlador o el sistema de archivos, y evita que un estado de solo lectura de protección se convierta en un problema de recuperación mayor.