¿Por qué Immich recrea los archivos faltantes con el propietario incorrecto?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Immich no debería recrear silenciosamente un original de origen faltante como función genérica de recuperación. Si un objeto eliminado vuelve a aparecer, identifica primero si es una miniatura generada, un vídeo codificado, un artefacto de perfil, un archivo sidecar XMP u otro archivo escribible; distintos procesos pueden recrearlos o reescribirlos, y estos pueden heredar un propietario diferente.

Utiliza un objeto regenerado desechable y su directorio principal. Compara el UID/GID numérico y las ACL del host con el escritor efectivo dentro del contenedor; después, identifica si realmente lo creó Immich, una función que escribe archivos sidecar, un protocolo NAS u otro proceso del host. Evita ejecutar chown recursivo o chmod 777 hasta conocer al escritor.

Compara el archivo recreado con su directorio principal y con un archivo vecino correcto

Registra el propietario, el grupo, el modo, las ACL, los atributos extendidos si son relevantes y el UID/GID numérico del archivo recreado, de su directorio principal y de un archivo antiguo que funcione correctamente. Los nombres pueden inducir a error entre un NAS y un contenedor; los identificadores numéricos revelan si “immich” en un sistema corresponde a la misma identidad en otro.

El flujo de permisos de ZimaSpace para archivos movidos a un NAS se aplica directamente: los objetos nuevos se rigen por la ACL de destino, la identidad del contenedor, la asignación del protocolo y las reglas de creación. Por tanto, un archivo de reemplazo puede ser legible y aun así adquirir un propietario que interrumpa el flujo de trabajo de otra herramienta. Si el archivo recreado coincide con la herencia del directorio principal y solo el nombre mostrado parece desconocido, asigna el ID numérico antes de cambiar nada. Si difiere tanto del directorio principal como de los archivos correctos, continúa con la identidad del escritor; el problema puede estar en la configuración del contenedor y no en la ACL del sistema de archivos.

Identifica el proceso y el UID/GID efectivo que escribe el reemplazo

Activa una regeneración segura mientras supervisas los registros y el sistema de archivos pertinentes. Inspecciona el usuario y los grupos efectivos dentro del contenedor que realiza la escritura. Si el archivo lo crea un sidecar, una herramienta de metadatos, un proceso de copia de seguridad o un script del host, inspecciona ese servicio en lugar de cambiar la identidad de ejecución de Immich.

La propiedad en los contenedores es numérica, no se basa en nombres. Una explicación sobre la propiedad de archivos en Docker muestra por qué el mismo archivo montado mediante un enlace puede mostrar un nombre de usuario diferente en el host y en el contenedor cuando las asignaciones de UID/GID no coinciden. Utiliza los identificadores numéricos como referencia común.

Una discusión sobre la propiedad de bibliotecas externas en Immich documentó que los archivos sidecar XMP se escribían como root en una implementación. Es una evidencia para comprobar el escritor efectivo y la identidad de ejecución admitida, no una afirmación de que todas las instalaciones actuales de Immich escriban como root todos los archivos regenerados.

Si el contenedor se ejecuta intencionadamente con un usuario que no es root, confirma que el UID/GID realmente existe en el host o el NAS y que tiene el acceso necesario a la ruta montada. Un nombre de usuario simbólico dentro de un contenedor no coincide automáticamente con una cuenta del host que tenga el mismo nombre.

Corrige la regla de creación en lugar de reparar repetidamente los archivos existentes

Corrige el límite confirmado más pequeño: alinea el UID/GID del servicio cuando sea compatible, repara el grupo del directorio principal o la herencia de ACL, establece una umask adecuada o cambia la asignación del recurso compartido NAS que proporciona la identidad incorrecta. Conserva la capacidad de Immich y de cualquier otro lector legítimo para acceder a los originales y a los archivos generados.

No utilices permisos de escritura para todo el mundo como reparación predeterminada. Eso oculta la discrepancia de identidad y amplía innecesariamente el acceso de escritura. Del mismo modo, no cambies de forma recursiva la propiedad de PostgreSQL, la caché de modelos, las cargas y las bibliotecas externas con un solo comando; esas rutas pueden utilizar intencionadamente identidades de servicio diferentes.

Si una biblioteca externa debe ser inmutable, considera montar el recurso como de solo lectura y mantener en otro lugar el estado escribible propiedad de la aplicación, pero solo si las funciones que utilizas no requieren escribir archivos sidecar allí. La decisión debe basarse en la propiedad y el comportamiento de escritura deseados, no en obligar a que todos los archivos del archivo fotográfico compartan una sola cuenta.

Recrea un archivo y valida de nuevo después de reiniciar

Elimina únicamente un objeto generado desechable o un archivo sidecar de prueba que pueda recrearse sin riesgos; después, vuelve a activar exactamente la operación de Immich. Verifica el nuevo propietario, grupo, ACL y legibilidad desde Immich y desde el otro programa que anteriormente fallaba. Mantén intactos los archivos multimedia originales durante esta prueba.

Reinicia el contenedor y luego reinicia el host una vez para asegurarte de que la identidad y los montajes corregidos sobrevivan a los cambios del ciclo de vida. Una reparación correcta crea automáticamente el siguiente archivo de prueba con la propiedad esperada; no depende de un script chown posterior al arranque que compita con las escrituras de Immich.

Detente y restaura la configuración conservada si los cambios de propiedad se extienden inesperadamente a la base de datos o a los originales, o si el servicio pierde el acceso de lectura o escritura después de reiniciar. Escala el caso proporcionando los identificadores numéricos, la salida de las ACL, las opciones de montaje, el usuario efectivo del contenedor, el fragmento de Compose y el tipo exacto de archivo que Immich recreó.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.