La fuente identifica correctamente la capa real de propiedad: cuando un contenedor crea un directorio dentro de una carpeta de ZimaOS montada, el nuevo directorio normalmente hereda la identidad y el comportamiento de umask del proceso que se ejecuta dentro del contenedor, no los permisos que esperaba que la carpeta principal impusiera automáticamente.
Por eso, una carpeta principal con permisos de escritura para todos puede terminar teniendo subcarpetas nuevas pertenecientes a root:root con permisos 0755. Si la aplicación se ejecuta como root y usa un umask predeterminado, es normal que las carpetas secundarias sean propiedad de root, a menos que la imagen admita PUID/PGID, un usuario de contenedor específico, herencia de grupo mediante setgid, ACL predeterminadas u otro modelo de permisos.
El ejemplo de la fuente era una carpeta de respaldo montada
El usuario describió una ruta como:
/media/Daten/Backupdonde las subcarpetas nuevas pasaban a ser:
root:root
drwxr-xr-xUn usuario no root, como el UID 999, podía entonces leer, pero no crear archivos en esas nuevas carpetas secundarias.
Una carpeta principal con permisos 0777 no impone la propiedad de las subcarpetas
El permiso de escritura de la carpeta principal permite que el proceso del contenedor cree una carpeta secundaria. No hace que esta herede automáticamente el propietario o el grupo de la carpeta principal, a menos que el sistema de archivos o las reglas de grupo estén configurados para ello.
El UID/GID del creador y el umask del proceso determinan el resultado normal.
Usa PUID/PGID solo cuando la imagen del contenedor los admita
Muchas imágenes de estilo LinuxServer exponen las variables de entorno PUID y PGID. Otras imágenes ignoran por completo esas variables y requieren el campo user: de Docker o configuraciones específicas de la aplicación.
La documentación actual de Syncthing de IceWhale indica explícitamente a los usuarios que consulten los ID de usuario reales de ZimaOS con:
id -u username
id -g usernamey que después introduzcan esos valores en los campos PUID/PGID de la aplicación.
Consulta el ejemplo actual de PUID/PGID de ZimaOS.
umask controla qué bits de permiso se eliminan al crear archivos
Una aplicación que crea directorios con un modo base de 0777 y un umask típico de 022 producirá directorios con permisos 0755. Un flujo de trabajo de colaboración en grupo puede usar un umask diferente si la aplicación lo admite.
No establezcas globalmente un umask excesivamente permisivo solo para solucionar el problema de una aplicación.
setgid puede ayudar a mantener un grupo compartido en las subcarpetas nuevas
En sistemas de archivos nativos de Linux, establecer el bit setgid en una carpeta compartida puede hacer que los elementos secundarios nuevos hereden el grupo de la carpeta. Esto resulta útil cuando varios servicios o usuarios colaboran intencionadamente mediante un mismo grupo.
No cambia el ID de usuario del proceso que crea los elementos y puede no comportarse igual en montajes NTFS/exFAT que emulan la propiedad Unix mediante opciones de montaje.
Las ACL predeterminadas proporcionan una herencia más explícita
En sistemas de archivos compatibles con ACL POSIX, las entradas de ACL predeterminadas pueden definir los permisos que recibirán los elementos secundarios nuevos. Esto suele ser más limpio que ejecutar repetidamente chmod de forma recursiva después de cada tarea de respaldo.
Antes de depender de una configuración realizada únicamente mediante comandos de shell, debe verificarse si la interfaz actual de ZimaOS ofrece un flujo de trabajo completo de ACL para una ruta de almacenamiento determinada.
La fuente era una solicitud de función, no una configuración existente de ZimaOS
El autor solicitó un control global de PUID/PGID, un interruptor de herencia, gestión de umask, compatibilidad con setgid y una interfaz gráfica para realizar correcciones recursivas. El hilo no contiene ninguna respuesta de IceWhale que confirme que esas funciones se hayan implementado.
No presentes la lista de solicitudes como opciones actuales de Configuración.
Corrige la identidad de la aplicación antes de cambiar recursivamente todo el disco
Si una aplicación de respaldo vuelve a crear repetidamente carpetas propiedad de root, ejecutar chown -R después de cada tarea trata el síntoma. Configura primero correctamente la identidad, el grupo y el umask del contenedor; después, repara únicamente el árbol afectado.
La configuración actual de las aplicaciones de ZimaOS permite inspeccionar las asignaciones de volúmenes y la configuración de la aplicación, mientras que las variables de permisos exactas dependen de la imagen.
Preguntas frecuentes sobre la propiedad de carpetas montadas
¿Por qué una carpeta secundaria puede convertirse en root:root dentro de una carpeta principal con permisos de escritura?
Porque el proceso dentro del contenedor la creó como root y la carpeta principal no anula automáticamente la identidad del creador.
¿Funcionan PUID y PGID con todas las imágenes de Docker?
No. Son convenciones de variables de entorno específicas de cada imagen, no variables universales de Docker.
¿IceWhale confirmó en la fuente un interruptor global de herencia de permisos?
No. El hilo es una solicitud de función sin confirmación de implementación.
