Cómo solucionar un montaje bind de Docker que de repente se vuelve de solo lectura
Un montaje bind de Docker se vuelve de solo lectura cuando Docker recibe una ruta de solo lectura o el sistema de archivos del host deja de aceptar escrituras.
Como un montaje bind expone directamente una ruta del host dentro del contenedor, el contenedor no puede reparar por sí solo un disco, sistema de archivos, indicador de montaje o política de seguridad subyacente. La recuperación más segura consiste en detener las escrituras, comparar el montaje del contenedor con el montaje del host, determinar si el comportamiento de solo lectura se configuró o se activó debido a un error, y restaurar el estado del almacenamiento antes de reiniciar la aplicación.
Confirma qué ruta es de solo lectura
Prueba una escritura inocua dentro del contenedor en el destino del montaje bind y otra escritura en el host en la ruta de origen. Registra el error exacto en lugar de asumir que todo fallo de permisos significa que el sistema de archivos es de solo lectura.
Un caso del foro de Docker muestra que un montaje bind principal de solo lectura puede impedir que Docker cree un punto de montaje anidado, porque no se puede crear el directorio necesario en el sistema de archivos principal de solo lectura.
Si el host puede escribir pero el contenedor no, inspecciona las opciones de montaje de Docker y los controles de seguridad. Si ambos fallan con un error de sistema de archivos de solo lectura, deja de cambiar los usuarios del contenedor y traslada el diagnóstico al montaje del host y al dispositivo de almacenamiento.
Comprueba los indicadores de montaje efectivos de Docker
Inspecciona la configuración del contenedor en ejecución en lugar de consultar únicamente el archivo Compose actual. Confirma el origen, el destino, el modo de propagación y si el montaje está marcado como de solo lectura mediante :ro, la sintaxis larga, un archivo de anulación o una herramienta de implementación.
Un problema del cliente de Docker documenta casos en los que las rutas montadas aparecían como de solo lectura porque la configuración en tiempo de ejecución difería de la configuración prevista de lectura y escritura. La evidencia importante es el modo de montaje efectivo asociado al contenedor en ejecución.
Si el montaje es intencionadamente de solo lectura, elimina ese indicador únicamente cuando la aplicación realmente necesite escribir. Recrea el contenedor después de cambiar la declaración, porque editar un archivo Compose no modifica retroactivamente un montaje existente.
Determina si el host volvió a montar el sistema de archivos como de solo lectura
Comprueba la tabla de montajes del host, el registro del kernel, el registro de almacenamiento y el estado del sistema de archivos en busca de errores de E/S, fallos del diario, errores de suma de comprobación, reinicios del dispositivo o un remontaje de protección. No fuerces un remontaje de lectura y escritura antes de entender por qué se activó la protección.
Un caso de soporte de Unraid describe un fallo de appdata de Docker después de que un sistema de archivos se volviera de solo lectura, incluidos errores al crear directorios de Plex. Ese patrón apunta a un fallo del sistema de archivos del host y no a una configuración de permisos del contenedor.
Detén los contenedores afectados y conserva los diagnósticos. Repara el disco, la matriz, el cable, el sistema de archivos o el diario mediante el flujo de mantenimiento compatible con la plataforma y, después, confirma que la ruta del host está en buen estado antes de permitir que los contenedores de bases de datos o archivos multimedia vuelvan a escribir.
Inspecciona los montajes anidados y superpuestos
Enumera todos los montajes bind y volúmenes con nombre cuyo destino se encuentre dentro de otro directorio montado. Los montajes superpuestos pueden ocultar directorios, heredar comportamientos de acceso inesperados o requerir que Docker cree un punto de montaje debajo de un elemento principal de solo lectura.
Un debate de Server Fault explica que superponer un montaje de lectura y escritura con otro montaje más amplio de solo lectura en rutas relacionadas del contenedor puede producir resultados confusos. Como ese ámbito ya se utiliza en otra parte de este lote, la regla práctica aquí es mapear todo el árbol de destinos antes de cambiar los permisos.
Crea los directorios necesarios del host antes de iniciar el contenedor, evita montar un elemento secundario escribible debajo de un elemento principal de solo lectura cuando el entorno de ejecución deba crearlo y mantén explícitas las rutas persistentes en Compose. Recrea el contenedor después de simplificar el árbol de montajes.
Distingue el estado de solo lectura de los permisos y la política de seguridad
Compara el error de la prueba de escritura con el propietario, el modo, las ACL, la etiqueta de SELinux, el perfil de AppArmor y el ID de usuario del contenedor correspondientes al directorio de origen. «Permiso denegado» y «sistema de archivos de solo lectura» son fallos distintos que requieren reparaciones diferentes.
Una guía de solución de problemas de almacenamiento clasifica los incidentes de volúmenes de solo lectura en indicadores de montaje, errores del sistema de archivos, contextos de seguridad y problemas del controlador de almacenamiento. Esa clasificación ayuda a evitar responder ciegamente con chmod 777 ante un estado de solo lectura en la capa de almacenamiento.
Si los permisos son incorrectos, corrige el propietario o las ACL en el host usando el UID y el GID previstos para el contenedor. Si el propio sistema de archivos es de solo lectura, los cambios de permisos fallarán y no deben utilizarse como sustituto de la reparación del sistema de archivos.
Reinicia la aplicación solo después de que la prueba de escritura del host sea satisfactoria
Escribe, sincroniza, lee y elimina un archivo temporal en la ruta del host y, después, repite la prueba mediante un contenedor temporal que use la misma declaración de montaje y el mismo usuario. Confirma que el sistema de archivos esperado siga montado después de un reinicio.
La guía de ZimaSpace sobre cómo encontrar una dependencia del contenedor que provoca un bucle de reinicio es la siguiente comprobación si la aplicación sigue reiniciándose después de que el almacenamiento vuelva a ser escribible.
La reparación solo está completa cuando el sistema de archivos del host está en buen estado, el montaje efectivo de Docker está diseñado para permitir lectura y escritura, la aplicación puede actualizar sus archivos persistentes y no aparecen nuevos errores de E/S ni del sistema de archivos durante un uso prolongado.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
