Pourquoi Immich recrée-t-il les fichiers manquants avec le mauvais propriétaire ?

Immich ne devrait pas recréer silencieusement un original source manquant comme fonctionnalité générique de récupération. Si un objet supprimé réapparaît, déterminez d’abord s’il s’agit d’une miniature générée, d’une vidéo encodée, d’un artefact de profil, d’un fichier annexe XMP ou d’un autre fichier inscriptible ; ces fichiers peuvent être recréés ou réécrits par différents processus et hériter d’un propriétaire différent.

Utilisez un objet régénéré jetable et son répertoire parent. Comparez l’UID/GID numérique et les ACL sur l’hôte avec ceux du processus d’écriture effectif dans le conteneur, puis déterminez si Immich, une fonctionnalité d’écriture de fichiers annexes, un protocole NAS ou un autre processus de l’hôte a réellement créé le fichier. Évitez d’exécuter un chown récursif ou d’appliquer chmod 777 avant d’avoir identifié ce processus d’écriture.

Comparez le fichier recréé avec son parent et un fichier voisin connu comme fonctionnel

Notez le propriétaire, le groupe, le mode, les ACL, les attributs étendus s’ils sont pertinents, ainsi que l’UID/GID numérique du fichier recréé, de son répertoire parent et d’un fichier plus ancien qui fonctionne correctement. Les noms peuvent être trompeurs entre un NAS et un conteneur ; les identifiants numériques permettent de vérifier si « immich » sur un système correspond à la même identité sur l’autre.

Le processus de gestion des autorisations de ZimaSpace pour les fichiers déplacés vers un NAS s’applique directement : les nouveaux objets sont régis par les ACL de destination, l’identité du conteneur, la correspondance du protocole et les règles de création. Un fichier de remplacement peut donc être lisible tout en acquérant un propriétaire qui perturbe le fonctionnement d’un autre outil. Si le fichier recréé correspond à l’héritage du parent et que seul le nom affiché semble inhabituel, faites correspondre l’identifiant numérique avant de modifier quoi que ce soit. S’il diffère à la fois du parent et des fichiers connus comme fonctionnels, poursuivez l’analyse de l’identité du processus d’écriture ; le problème peut se trouver dans la configuration du conteneur plutôt que dans les ACL du système de fichiers.

Identifiez le processus et l’UID/GID effectif qui écrit le fichier de remplacement

Déclenchez une régénération sans risque tout en surveillant les journaux et le système de fichiers concernés. Inspectez l’utilisateur et les groupes effectifs à l’intérieur du conteneur qui effectue l’écriture. Si un fichier annexe, un outil de métadonnées, un processus de sauvegarde ou un script de l’hôte crée le fichier à la place, inspectez ce service plutôt que de modifier l’identité d’exécution d’Immich.

La propriété des fichiers dans un conteneur repose sur des valeurs numériques et non sur les noms. Une explication de la propriété des fichiers Docker montre pourquoi le même fichier monté peut afficher un nom d’utilisateur différent sur l’hôte et dans le conteneur lorsque les correspondances UID/GID ne concordent pas. Utilisez les identifiants numériques comme référence commune.

Une discussion sur la propriété des bibliothèques externes d’Immich a documenté l’écriture de fichiers annexes XMP par root dans un déploiement. Il s’agit d’un élément justifiant la vérification du processus d’écriture effectif et de l’identité d’exécution prise en charge, et non d’une affirmation selon laquelle toutes les installations actuelles d’Immich écrivent chaque fichier régénéré en tant que root.

Si le conteneur s’exécute intentionnellement avec un utilisateur non root, vérifiez que l’UID/GID existe réellement sur l’hôte ou le NAS et dispose des accès requis au chemin monté. Un nom d’utilisateur symbolique à l’intérieur d’un conteneur ne correspond pas automatiquement à un compte hôte portant le même nom.

Réparez la règle de création au lieu de corriger sans cesse les fichiers existants

Corrigez la plus petite frontière confirmée : alignez l’UID/GID du service lorsque cela est pris en charge, réparez l’héritage du groupe ou des ACL du répertoire parent, définissez un umask approprié ou modifiez la correspondance du partage NAS qui fournit la mauvaise identité. Préservez la capacité d’Immich et de tout autre lecteur légitime à accéder aux originaux et aux fichiers générés.

N’utilisez pas les autorisations d’écriture pour tous comme solution par défaut. Cela masque le problème de correspondance d’identité et élargit inutilement les accès en écriture. De même, ne modifiez pas récursivement la propriété de PostgreSQL, du cache des modèles, des téléversements et des bibliothèques externes avec une seule commande ; ces chemins peuvent intentionnellement utiliser des identités de service différentes.

Si une bibliothèque externe est censée être immuable, envisagez de monter le volume en lecture seule et de conserver ailleurs les données inscriptibles appartenant à l’application, mais uniquement si les fonctionnalités que vous utilisez n’exigent pas l’écriture de fichiers annexes à cet emplacement. La décision doit porter sur la propriété et le comportement d’écriture souhaités, et non sur l’obligation de faire partager un même compte à tous les fichiers de l’archive photo.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Recréez un fichier et validez le résultat après un redémarrage

Supprimez uniquement un objet généré jetable ou un fichier annexe de test qui peut être recréé sans risque, puis déclenchez à nouveau l’opération Immich exacte. Vérifiez le nouveau propriétaire, le groupe, les ACL et la lisibilité depuis Immich et depuis l’autre programme qui rencontrait auparavant un problème. Ne touchez pas aux fichiers multimédias originaux pendant ce test.

Redémarrez le conteneur, puis redémarrez une fois l’hôte pour vérifier que l’identité et les montages corrigés résistent aux changements de cycle de vie. Une réparation réussie crée automatiquement le fichier de test suivant avec la propriété attendue ; elle ne dépend pas d’un script chown exécuté au démarrage, qui entrerait en conflit avec les écritures d’Immich.

Arrêtez le service et restaurez la configuration sauvegardée si les changements de propriété s’étendent de manière inattendue à la base de données ou aux originaux, ou si le service perd ses accès en lecture/écriture après le redémarrage. Fournissez les identifiants numériques, la sortie des ACL, les options de montage, l’utilisateur effectif du conteneur, l’extrait Compose et le type exact de fichier recréé par Immich lors de l’escalade du problème.