¿Por qué cambian los propietarios de los archivos de los contenedores después de copiar los datos de la aplicación?
Los propietarios de los archivos de un contenedor cambian después de una copia cuando no se conservan los valores numéricos de UID/GID o el entorno de destino los reasigna o reescribe.
En un NAS doméstico, el mismo archivo puede mostrar un nombre de usuario en el host y otro dentro de un contenedor porque la propiedad se almacena como números, mientras que cada entorno resuelve esos números mediante una base de datos de cuentas diferente. Las copias realizadas mediante una interfaz gráfica, un recurso compartido SMB, un archivo comprimido, un shell de root, una herramienta de migración o un punto de entrada del contenedor también pueden sustituir la propiedad. Diagnostica primero la identidad numérica y, después, separa el comportamiento de la copia, la configuración del usuario en tiempo de ejecución, los scripts de inicio, los espacios de nombres de usuario y la asignación del sistema de archivos de red antes de cambiar los permisos de todo el árbol de datos de la aplicación.
Compara los UID y GID numéricos antes que los nombres de usuario
Inspecciona el origen y el destino con la propiedad numérica, no solo con los nombres. Registra el UID, el GID, el modo, las ACL, los atributos extendidos y el sistema de archivos de un archivo representativo y de su directorio principal, tanto en el host como dentro del contenedor.
Los montajes vinculados de Docker exponen los archivos del host a procesos que pueden utilizar una base de datos de usuarios diferente. Un debate de la comunidad de Docker explica por qué el acceso fiable depende de la coincidencia de UID/GID numéricos, no solo de que coincidan los nombres de usuario.
Si los números son idénticos pero los nombres mostrados difieren, es posible que la propiedad no haya cambiado. Corrige la documentación o la asignación de cuentas en lugar de reescribir los datos de forma recursiva. Si los números difieren, conserva las pruebas y continúa con las etapas de copia y ejecución.
Determina si la copia conservó o recreó la propiedad
Anota la ruta exacta de la copia: gestor de archivos del host, cp, rsync, archivo tar, cliente SMB/NFS, restauración de una copia de seguridad, comando de copia de Docker o contenedor de migración temporal. Cada método tiene valores predeterminados diferentes para el propietario, el grupo, las ACL y los atributos extendidos.
Una copia ejecutada como root puede conservar la propiedad numérica cuando se utilizan opciones de archivo explícitas, mientras que otra herramienta puede crear todos los archivos de destino con la cuenta que realiza la copia. Un problema reciente de migración de contenedores muestra cómo los datos de una aplicación copiados pueden volverse ilegibles cuando el UID de destino difiere de la identidad de ejecución de la aplicación.
Repite la operación con un directorio de prueba pequeño e inspecciona la propiedad inmediatamente antes de iniciar la aplicación. Si los números ya son incorrectos, corrige el método de copia o restaura las opciones adecuadas. Si solo cambian después del inicio, no modifiques la copia e investiga el punto de entrada del contenedor.
Haz coincidir el usuario de ejecución del contenedor con el propietario del almacenamiento en el host
Inspecciona el usuario efectivo dentro del contenedor en ejecución y el propietario numérico del directorio de datos de la aplicación montado mediante enlace. Comprueba también user: en Compose, los grupos suplementarios, las variables PUID/PGID de la plataforma y cualquier configuración de cuenta específica de la imagen.
Ejecutar un contenedor con un usuario que no sea root no concede automáticamente acceso a un directorio del host propiedad de otra identidad numérica. Un caso del foro de Docker resuelve esta limitación haciendo coincidir el usuario del contenedor y los permisos del host, en lugar de hacer que el directorio fuera escribible para cualquiera.
Elige un modelo de propiedad estable para la aplicación y documéntalo en Compose. Añade únicamente los grupos necesarios para el acceso compartido. Evita chmod 777, porque oculta la discrepancia de identidad, debilita la separación y no conserva el propietario previsto para los archivos futuros.
Comprueba si el punto de entrada cambia la propiedad al iniciar
Muchas imágenes se inician brevemente como root, crean los directorios que faltan, aplican un UID/GID configurado y cambian la propiedad de forma recursiva antes de reducir privilegios. Ese comportamiento puede hacer que una copia correcta parezca cambiar por sí sola después del primer inicio del contenedor.
Los tiempos de ejecución y las imágenes de contenedores también pueden ofrecer funciones de montaje que cambian la propiedad. Un problema de Podman señala que la opción :U puede reescribir la propiedad del origen, mientras que los scripts de punto de entrada pueden realizar un cambio recursivo similar durante el inicio de la aplicación.
Inicia el contenedor una vez con los registros visibles y supervisa un subárbol pequeño de prueba. Busca en el punto de entrada y en las notas de la versión de la imagen términos como chown, migración de usuarios, PUID/PGID y pasos de corrección de permisos. Desactiva o limita ese comportamiento solo cuando la imagen admita una alternativa estable.
Ten en cuenta Docker rootless, los espacios de nombres de usuario y los sistemas de archivos de red
Docker rootless y la reasignación de espacios de nombres de usuario traducen los identificadores del contenedor a otro rango del host. NFS, CIFS y algunas opciones de montaje de NAS pueden aplicar por separado squash de root o forzar que todos los archivos utilicen un UID y un GID configurados.
Un informe sobre permisos de Docker rootless muestra archivos con una propiedad inesperada porque la identidad del contenedor se asigna mediante un rango subordinado del host. La pista diagnóstica es la asignación de propiedad mediante espacios de nombres de usuario, no un fallo de copia convencional.
Comprueba si la ruta de datos es local, NFS, CIFS, FUSE u otro sistema de archivos montado y registra su comportamiento con UID/GID, root-squash y ACL. Prueba por separado la creación de propiedad desde el host y desde el contenedor. No ejecutes un chown recursivo en un recurso compartido de red hasta comprender la política de identidad del servidor.
Repara la propiedad a partir de una identidad conocida de la aplicación
Detén la aplicación, realiza una copia de seguridad de los metadatos actuales y define el UID, el GID, los modos de directorio, los modos de archivo, las ACL y las etiquetas de seguridad exactos que espera la imagen. Corrige únicamente las rutas propiedad de la aplicación, excluyendo los medios compartidos u otros conjuntos de datos no relacionados.
La guía de ZimaSpace sobre cómo separar los fallos de permisos de los montajes de solo lectura es la siguiente comprobación cuando una propiedad correcta todavía no permite escribir.
Reinicia el contenedor y crea, modifica y elimina un archivo de prueba como el usuario real del servicio. Después, recrea el contenedor y repite la prueba. La reparación solo estará completa cuando la propiedad permanezca estable después de copiar, iniciar, reiniciar y recrear el contenedor, y la aplicación pueda leer y escribir sin excepciones de permisos generales.
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...
