Cómo configurar los identificadores de usuario de los contenedores en varios recursos compartidos de NAS

Configura los identificadores de usuario de los contenedores en varios recursos compartidos del NAS asignando la identidad numérica real de cada proceso del contenedor al propietario, grupo, ACL y modo de montaje de cada recurso compartido que necesite.

No obligues a un único UID a ser propietario de todos los conjuntos de datos ni uses chmod 777 como estrategia de integración. Un servidor multimedia puede necesitar acceso de solo lectura a las fotos, un descargador puede necesitar acceso de lectura y escritura a un recurso compartido de recepción, y un contenedor de copias de seguridad puede necesitar un destino protegido diferente. Usa la propiedad para la responsabilidad principal y los grupos o las ACL para el acceso compartido.

Registra las tres identidades antes de cambiar los permisos

Para cada servicio, registra el UID/GID del propietario en el NAS, el usuario y los grupos numéricos del proceso dentro del contenedor, y cualquier convención de identidad específica de la imagen, como PUID/PGID. Estos tres valores suelen confundirse porque los nombres de usuario pueden parecer idénticos aunque los identificadores numéricos sean diferentes.

Una explicación actualizada sobre qué hacen PUID y PGID no son configuraciones de Docker deja clara la diferencia: PUID y PGID son variables interpretadas por determinadas imágenes de contenedor, no configuraciones universales de Docker.

Verifica el proceso en ejecución con id dentro del contenedor e inspecciona los archivos del host con la propiedad numérica. No des por hecho que los valores escritos en Compose controlan realmente el proceso, a menos que la imagen admita ese método.

Usa un propietario principal y grupos compartidos para los datos entre servicios

Un recurso compartido utilizado por una sola aplicación puede tener un propietario dedicado. Un recurso compartido en el que escriben varios servicios suele ser más fácil de gestionar con un grupo compartido definido deliberadamente o con una ACL que conceda solo las operaciones que esos servicios necesitan.

Una explicación práctica de la propiedad mediante UID y GID numéricos muestra por qué los archivos montados mediante enlace siguen la propiedad numérica del host y por qué hacer coincidir o asignar deliberadamente esos identificadores evita que los archivos generados pertenezcan a root y previene errores de permisos.

Por ejemplo, en un flujo multimedia, el descargador puede ser propietario de sus archivos de preparación, mientras que tanto el descargador como el organizador pertenecen a un grupo media. Configura la herencia de directorios, las ACL predeterminadas o un comportamiento adecuado de umask para que los archivos nuevos mantengan automáticamente el acceso compartido.

Concede a cada recurso compartido solo los derechos de montaje que necesita el contenedor

La identidad es solo una capa. Un UID correctamente asignado aún no puede escribir mediante un montaje de enlace de solo lectura, y un contenedor con permisos amplios en el sistema de archivos puede seguir estando limitado de forma segura si montas una biblioteca como solo lectura.

Una explicación de 2026 sobre las sobrescrituras del usuario en tiempo de ejecución explica cómo los montajes de enlace utilizan la propiedad del host y cómo la configuración user: en tiempo de ejecución puede alinear los identificadores de los procesos, aunque también advierte que forzar un usuario puede romper imágenes cuya lógica de inicio espera privilegios diferentes.

Documenta cada ruta del host, ruta del contenedor, modo de montaje, operaciones necesarias y servicio responsable. Usa montajes de solo lectura para las bibliotecas que un servicio solo consume y reserva el acceso de escritura para la ruta más pequeña que realmente lo necesite.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gestiona deliberadamente los distintos modelos de ACL del NAS

Las ACL de SMB/NFSv4, las ACL de POSIX, la asignación de identidades de NFS y los simples bits de modo de Unix pueden mostrar distintas perspectivas del acceso. Un recurso compartido que funciona mediante SMB como un usuario del NAS aún puede rechazar un proceso de contenedor que utilice una identidad numérica diferente en el host.

El artículo relacionado de ZimaSpace sobre los cambios en los permisos del NAS muestra por qué la herencia de ACL del destino, la identidad de SMB, el UID/GID del contenedor y umask deben diagnosticarse como capas independientes.

Cuando varios protocolos accedan al mismo conjunto de datos, elige un modelo de permisos y documéntalo. Mezclar repetidamente cambios de ACL desde la interfaz gráfica del NAS con comandos de shell chmod y chown puede hacer que el siguiente archivo se comporte de forma diferente al anterior.

Prueba la creación de archivos desde cada escritor antes de aplicar cambios de forma recursiva

Crea un directorio de prueba desechable con la propiedad y la ACL previstas. Desde cada contenedor, prueba a listar, leer, crear, renombrar y eliminar únicamente las operaciones que necesite el servicio. Después, inspecciona desde el NAS el propietario numérico, el grupo, el modo y la ACL heredada del archivo nuevo.

Si los archivos antiguos funcionan pero los recién creados fallan para otro servicio, corrige la ruta de creación: la pertenencia al grupo, la ACL predeterminada, umask o el modo de archivo específico de la aplicación. Una reparación recursiva de los datos antiguos no evita que el mismo desajuste vuelva a aparecer mañana.

Implementa los cambios en producción solo después de que cada escritor cree archivos que el siguiente servicio necesario pueda utilizar sin privilegios elevados. Un diseño limpio de UID/GID es recuperable porque la asignación está documentada y se puede repetir, no porque todos los contenedores se ejecuten por casualidad como el mismo usuario.