Prevenir la deriva de permisos en Immich implica hacer predecibles la propiedad de los archivos y las reglas de acceso antes de que distintos contenedores, protocolos NAS, actualizaciones o tareas de mantenimiento creen archivos nuevos con identidades diferentes.
La solución duradera no consiste en restablecer periódicamente los permisos de forma recursiva. Registra los UID/GID numéricos y el acceso que realmente necesita cada flujo de trabajo, mantén deliberadamente la propiedad de los montajes y la herencia de ACL, separa las rutas de solo lectura de las que permiten escritura y prueba la ruta de creación después de cada cambio. La deriva de permisos se previene cuando el archivo nuevo de mañana se crea correctamente sin un `chown` de emergencia, no cuando la biblioteca de hoy resulta ser legible.
Registra las identidades que leen y escriben en cada ruta de Immich
Enumera las rutas del host montadas en Immich e identifica qué procesos deben leer, crear, cambiar de nombre o eliminar archivos en cada una. Para cada proceso que escriba, registra su UID y GID numéricos en el host y dentro del contenedor. Los ID numéricos son más importantes que los nombres de usuario coincidentes porque los archivos almacenan la propiedad como números.
Incluye en el inventario los procesos que no pertenecen a Immich. Las cargas mediante SMB, los clientes NFS, las herramientas de copia de seguridad, los scripts de importación, los contenedores de gestión multimedia y una shell de administrador pueden crear archivos en el mismo árbol. Si lo hacen con identidades diferentes, la biblioteca puede acumular gradualmente propietarios y modos que funcionan en una ruta, pero fallan en otra.
Conserva este mapa de identidades junto con la configuración de Compose. Así, una futura actualización de imagen, migración del servidor o cuenta NAS restaurada podrá compararse con una referencia conocida y correcta, en lugar de descubrir el desajuste solo después de que empiecen a fallar las nuevas cargas.
Usa un modelo deliberado de propietario, grupo compartido y acceso mínimo
Decide qué identidad debe ser propietaria de los datos gestionados por la aplicación y qué grupo compartido, si lo hay, necesita acceso. Concede a cada flujo de trabajo únicamente los permisos de lectura o escritura que requiera. Evita hacer escribible para todo el mundo el árbol completo de Immich simplemente porque un contenedor no puede crear una miniatura o mover un archivo importado.
Los desajustes de UID/GID y los modos demasiado amplios son causas habituales de fallos en volúmenes compartidos. El patrón más seguro consiste en alinear los permisos del contenedor y del volumen en lugar de conceder acceso sin restricciones. Esto es importante en un servidor doméstico donde varios servicios pueden acceder al mismo conjunto de almacenamiento.
Si varios servicios necesitan acceso de escritura, utiliza un grupo compartido y permisos de grupo o ACL coherentes, en lugar de alternar la propiedad recursiva entre aplicaciones. Verifica primero un directorio representativo. Los cambios recursivos amplios en toda la biblioteca de fotos deben ser el último recurso y realizarse con una copia de seguridad actual, no como mantenimiento rutinario.
Haz predecibles los permisos de los archivos nuevos
Los archivos existentes pueden parecer perfectos mientras los nuevos empiezan a desviarse de inmediato porque las reglas de creación son incorrectas. Comprueba la ACL del directorio principal, las entradas de ACL predeterminadas, la umask, la identidad del servicio y cualquier configuración de creación de SMB o NFS aplicable a la ruta. El objetivo de la prevención es la herencia, no la limpieza.
Antes de cambiar modos de forma recursiva, compara la propiedad numérica en el host con el UID/GID que realmente se ejecuta dentro del contenedor. Esta comprobación de UID/GID del bind mount permite distinguir rápidamente un desajuste de identidad de un permiso realmente ausente. Corrige la relación entre propietario y grupo en lugar de ocultarla con modos permisivos.
Crea un archivo de prueba pequeño mediante cada ruta de escritura normal: carga en Immich, flujo de importación, transferencia SMB/NFS si se utiliza y restauración de una copia de seguridad. Inspecciona el propietario, el grupo, el modo y la ACL después de cada prueba. Si dos rutas de creación producen resultados incompatibles, resuelve ese conflicto de políticas antes de importar más datos.
Evita que los cambios de montaje y actualización reescriban la propiedad
Trata una edición de Compose, una actualización de imagen, un remontaje del NAS o una migración como un cambio sensible a los permisos. Antes de aplicarlo, registra el origen y el destino actuales del montaje, si la ruta es de solo lectura o de lectura y escritura, el usuario efectivo del contenedor y una muestra de la propiedad numérica de cada directorio importante.
Las transferencias y el almacenamiento en red pueden introducir identidades SMB/NFS diferentes, ID numéricos, herencia de ACL y comportamientos de umask distintos. Utiliza los puntos de fallo de los cambios de permisos en NAS como lista de comprobación previa al cambio cada vez que los datos de Immich se muevan entre sistemas de archivos o métodos de acceso.
Después del cambio, compara las mismas muestras antes de ejecutar trabajos masivos. Si la propiedad cambia repentinamente al iniciar, detén la pila e identifica qué punto de entrada, tarea de mantenimiento o identidad reasignada lo provocó. No permitas que una reescritura recursiva de la propiedad sin explicación continúe por una biblioteca grande.
Audita la deriva con pruebas pequeñas y repetibles
Realiza una auditoría ligera de permisos según un calendario o después de las actualizaciones: comprueba algunos originales estables, una carga reciente, un derivado generado recientemente y cualquier montaje de biblioteca externa. Busca propietarios inesperados, acceso de grupo ausente, montajes de solo lectura que se hayan vuelto escribibles o ACL que ya no se hereden como se esperaba.
Después, realiza una prueba de escritura de extremo a extremo. Carga un recurso desechable mediante el cliente habitual, deja que Immich lo procese, ábrelo y elimínalo desde la aplicación. Si las rutas de bibliotecas externas o importación forman parte de tu configuración, añade un archivo representativo mediante esas rutas y confirma que Immich pueda leerlo sin cambiar la propiedad inesperadamente.
El ciclo de prevención solo se completa cuando los archivos nuevos siguen recibiendo la identidad y el acceso previstos después de reiniciar Immich y de reiniciar el host. Si los permisos requieren una reparación manual después de cualquiera de estos eventos, el sistema sigue presentando deriva; corrige la regla de creación o la asignación de identidades antes de ampliar el acceso.
Soporte y Consejos
Más para leer

Cómo optimizar las conexiones de la base de datos de Immich para contenedores simultáneos
No aumentes primero max_connections. Mide las sesiones de Immich, suma la demanda total de todos los contenedores, conserva margen para la administración y ajusta...

Cómo evitar trabajos o importaciones duplicados en Immich
Separa los trabajos repetidos de los recursos duplicados. Usa una única ruta de ingesta canónica, controla los reintentos y los cambios de ruta, y...

Cómo reparar Immich después de que su volumen de base de datos se llene
Nunca elimines el WAL de PostgreSQL para liberar espacio. Detén las escrituras de Immich, conserva el estado de la base de datos, añade capacidad...

