¿Podrá tu aplicación Docker escribir en sus datos? Lista de verificación de permisos de volúmenes

Por qué un contenedor en ejecución puede no poder escribir

Un contenedor puede iniciarse con normalidad aunque la aplicación no pueda crear, actualizar ni eliminar archivos en un directorio de datos montado. Que el contenedor se inicie no demuestra que la aplicación tenga el acceso que necesita.

El acceso depende de la identidad efectiva del proceso y de los permisos de la ruta montada. También pueden influir un montaje de solo lectura, los directorios padre, las ACL, SELinux o las asignaciones de espacios de nombres de usuario. Comprueba la ruta y la operación concretas antes de cambiar permisos. Para información sobre montajes, consulta la documentación de Docker sobre [montajes bind](https://docs.docker.com/engine/storage/bind-mounts/) y [volúmenes](https://docs.docker.com/engine/storage/volumes/).

• Anota el error y la ruta exacta implicada.
• Identifica qué operación falla: crear, modificar, eliminar o acceder a un directorio.
• No cambies permisos de forma recursiva sin identificar antes la causa.

Identifica la identidad del proceso y la ruta montada

Comprueba la configuración del contenedor y los montajes que informa Docker. Para un contenedor llamado myapp, ejecuta:

docker inspect --format '{{json .Mounts}}' myapp

Revisa el origen, el destino, el tipo y la configuración de lectura y escritura. Un montaje bind apunta a una ruta del host; un volumen con nombre lo gestiona Docker. Confirma que el destino sea la ruta que la aplicación intenta usar.

Después, ejecuta docker exec myapp id. Ese comando muestra la identidad de la sesión exec, que puede no coincidir con la del proceso de la aplicación si un punto de entrada abandona privilegios antes de iniciarla. Consulta la documentación de la imagen o la aplicación y, cuando sea posible, verifica el proceso en ejecución.

Compara los ID numéricos de usuario y grupo, no solo los nombres. En un montaje bind convencional de Linux sin reasignación de usuarios, la propiedad se basa en valores numéricos; el mismo nombre de cuenta en dos imágenes puede corresponder a ID distintos. La documentación de Docker explica también las [asignaciones de espacios de nombres de usuario](https://docs.docker.com/engine/security/userns-remap/).

• Registra el destino del montaje y su origen en el host, o el nombre del volumen.
• Confirma la identidad efectiva del proceso de la aplicación y sus grupos.
• Compara los UID y GID numéricos.

Comprueba la propiedad y los controles del host

En un host Linux, inspecciona la propiedad y los permisos numéricos de la ruta de origen del montaje bind. Sustituye /srv/myapp/data por la ruta real:

ls -ln /srv/myapp/data stat -c '%u:%g %a %n' /srv/myapp/data

Comprueba también los directorios padre: el proceso necesita acceso adecuado a lo largo de la ruta, no solo en el directorio final. Si está disponible, namei -l /srv/myapp/data permite revisar los permisos de sus componentes.

Si la propiedad y los bits de permisos no explican el problema, comprueba las ACL con getfacl y, en los sistemas que usan SELinux, inspecciona el contexto con ls -Z. Para estas comprobaciones, consulta la documentación de [getfacl](https://man7.org/linux/man-pages/man1/getfacl.1.html) y la [documentación de SELinux de Red Hat](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/index). Docker sin privilegios y la reasignación de espacios de nombres de usuario también pueden hacer que los ID del host difieran de los que se ven dentro del contenedor; consulta la documentación de [Docker sin privilegios](https://docs.docker.com/engine/security/rootless/) si corresponde.

• Compara la identidad del proceso con el propietario, el grupo y los permisos de la ruta.
• Revisa tanto el directorio final como sus directorios padre.
• Si las comprobaciones básicas no bastan, investiga las ACL, SELinux y las asignaciones de identidad.

Prueba las operaciones que la aplicación necesita

Ver una lista de permisos no sustituye a una prueba. Comprueba primero que Docker no haya montado la ruta como de solo lectura: ese ajuste puede impedir que la aplicación guarde datos aunque el directorio subyacente parezca escribible.

Haz una prueba con la identidad efectiva de la aplicación y en el destino montado, usando mktemp para crear un archivo temporal de forma exclusiva, sin truncar un archivo preexistente. Si la imagen incluye un intérprete de comandos, mktemp y la aplicación se ejecuta con UID 1000 y GID 1000, un ejemplo básico es:

docker exec --user 1000:1000 myapp sh -c 'f=$(mktemp /data/.permission-test.XXXXXX) && rm "$f"'

Sustituye los ID y /data por los valores de tu implementación. La prueba crea un archivo temporal con un nombre único y elimina el archivo que ha creado; no cubre necesariamente otras operaciones, como actualizar un archivo existente, crear un subdirectorio o cambiarle el nombre. También puede no reproducir los grupos suplementarios u otros detalles del proceso real. Si la imagen no incluye mktemp, usa una prueba equivalente que cree el archivo de forma exclusiva o confirma el resultado desde la propia aplicación.

• Usa mktemp en el directorio montado real y elimina después el archivo creado.
• Prueba otras operaciones solo si la aplicación las necesita.
• Si la prueba funciona pero la aplicación falla, vuelve a comprobar su ruta, identidad, grupos y mensaje de error.

Resuelve las discrepancias de UID y GID sin usar chmod 777

Si la propiedad numérica no coincide con la identidad de la aplicación, elige una solución acorde con el acceso previsto. Confirma primero la identidad documentada de la aplicación en tiempo de ejecución y si otros servicios o administradores también necesitan acceder.

Para un directorio compartido, coordina un grupo que incluya las identidades pertinentes y concede solo el acceso necesario. El bit setgid, la umask y las ACL predeterminadas pueden influir en el acceso a los archivos nuevos; dar permiso de escritura al grupo en los archivos existentes no garantiza que los futuros sigan siendo accesibles para ese grupo. Para más información sobre estos efectos y el acceso compartido, consulta [Manage permissions on shared Docker volumes](https://guance.com/learn/articles/question-387-docker?lang=en&gc_source=learn_log-management-hk).

No uses chmod 777 como solución general: concede acceso amplio y no resuelve un montaje de solo lectura ni una restricción de SELinux. Aplica el cambio más limitado que corrija la causa confirmada y conserva una copia de seguridad antes de hacer cambios amplios de propiedad.

• Antes de cambiar la propiedad, confirma el UID previsto y el alcance del cambio.
• Si varios procesos necesitan acceso, revisa el grupo, sus miembros, setgid, la umask y las ACL predeterminadas.
• Corrige la configuración de solo lectura únicamente si la aplicación debe escribir en esa ruta.

Vuelve a comprobar los permisos tras cambios de imagen o implementación

Una implementación que antes funcionaba puede fallar después de un cambio de imagen o de host. La nueva imagen puede ejecutar la aplicación con otra identidad numérica; al migrar, también pueden cambiar la propiedad del directorio bind y los controles de acceso del host.

Los volúmenes con nombre requieren una comprobación aparte. Normalmente, un volumen vacío se rellena inicialmente con el contenido del directorio de la imagen sobre el que se monta, salvo que se desactive esa copia. Un volumen existente no recupera la propiedad de la imagen en cada inicio. Los controladores y las opciones de montaje pueden alterar el comportamiento; consulta la documentación de Docker sobre [volúmenes](https://docs.docker.com/engine/storage/volumes/) e inspecciona el montaje real.

Si usas Docker sin privilegios o la reasignación de espacios de nombres de usuario, verifica la asignación de identidades antes de cambiar la propiedad en el host. No bases un chown únicamente en un UID visto dentro del contenedor.

• Antes de actualizar, comprueba si cambiaron la identidad de ejecución o las rutas de datos.
• Antes de migrar, registra la propiedad numérica, las ACL, el contexto de seguridad y la configuración del montaje.
• Distingue entre un volumen con nombre recién creado y uno existente; verifica su contenido y propiedad actuales.

Documenta el acceso previsto y verifica la recuperación

Guarda un registro breve de la ruta de datos, el tipo de volumen, el UID y los grupos de la aplicación, las operaciones necesarias y cualquier configuración deliberada de ACL o seguridad del host. Anota también si el montaje es de solo lectura y si se reasignan identidades.

Después de una migración, actualización o cambio de implementación, repite la inspección y la prueba. Confirma que la aplicación pueda realizar las operaciones que necesita y conserva una copia recuperable de los datos importantes antes de cambiar su propiedad o los controles de acceso.

La implementación gestionada puede reducir el trabajo de infraestructura, pero no elimina la necesidad de tomar decisiones sobre los datos, el acceso y la recuperación. Airbip ofrece implementación gestionada para aplicaciones de su catálogo que se ejecutan como cargas de trabajo Docker en servidores en la nube de Airbip, con gestión del ciclo de vida del servicio y copias de seguridad diarias, semanales y mensuales configurables. Consulta el sitio web actual de Airbip para conocer los planes y condiciones vigentes, y verifica que la modalidad se ajuste a tus requisitos operativos y de datos.

• Documenta identidades, detalles del montaje, operaciones previstas y controles no predeterminados.
• Repite la prueba real tras cambios y resuelve los fallos antes de confiar en la implementación.
• Aclara las responsabilidades sobre la propiedad de los datos y su recuperación, tanto en alojamiento propio como gestionado.