Comment éviter la dérive des autorisations dans les dossiers de données d’Immich

Prévenir la dérive des permissions dans Immich consiste à rendre prévisibles la propriété des fichiers et les règles d’accès avant que différents conteneurs, protocoles NAS, mises à jour ou tâches de maintenance ne créent de nouveaux fichiers avec des identités différentes.

La solution durable n’est pas de réinitialiser périodiquement les permissions de manière récursive. Notez l’UID/GID numérique et les accès réellement nécessaires à chaque workflow, définissez soigneusement la propriété des points de montage et l’héritage des ACL, séparez les chemins en lecture seule de ceux accessibles en écriture, puis testez le processus de création après chaque modification. La dérive des permissions est évitée lorsque le prochain fichier est créé correctement sans nécessiter de `chown` d’urgence, et non lorsque la bibliothèque actuelle est simplement lisible.

Notez les identités qui lisent et écrivent dans chaque chemin Immich

Répertoriez les chemins de l’hôte montés dans Immich et identifiez les processus censés lire, créer, renommer ou supprimer des fichiers dans chacun d’eux. Pour chaque processus d’écriture, notez son UID et son GID numériques sur l’hôte et dans le conteneur. Les identifiants numériques comptent davantage que les noms d’utilisateur correspondants, car les fichiers enregistrent la propriété sous forme de nombres.

Incluez les processus d’écriture non liés à Immich dans l’inventaire. Les téléversements SMB, les clients NFS, les outils de sauvegarde, les scripts d’importation, les conteneurs de gestion multimédia et un shell d’administrateur peuvent tous créer des fichiers dans la même arborescence. S’ils utilisent des identités différentes, la bibliothèque peut progressivement accumuler des propriétaires et des modes qui fonctionnent pour un chemin, mais échouent pour un autre.

Conservez cette cartographie des identités avec la configuration Compose. Une future mise à jour d’image, migration de serveur ou restauration de compte NAS pourra alors être comparée à une référence connue comme fonctionnelle, au lieu de découvrir l’incompatibilité seulement après l’échec de nouveaux téléversements.

Utilisez un modèle délibéré fondé sur un propriétaire, un groupe partagé et un accès minimal

Décidez quelle identité doit posséder les données gérées par l’application et quel groupe partagé, le cas échéant, doit y accéder. Accordez à chaque workflow uniquement les droits de lecture ou d’écriture dont il a besoin. Évitez de rendre toute l’arborescence Immich accessible en écriture à tous simplement parce qu’un conteneur ne peut pas créer une miniature ou déplacer un fichier importé.

Les incompatibilités d’UID/GID et les modes trop permissifs sont des causes courantes d’échec avec les volumes partagés. La méthode la plus sûre consiste à aligner les permissions des conteneurs et des volumes plutôt qu’à accorder un accès sans restriction. C’est particulièrement important sur un serveur domestique où plusieurs services peuvent utiliser le même pool de stockage.

Si plusieurs services doivent disposer d’un accès en écriture, utilisez un groupe partagé et des permissions de groupe ou des ACL cohérentes, plutôt que d’alterner la propriété récursive entre les applications. Vérifiez d’abord un répertoire représentatif. Les modifications récursives étendues sur l’ensemble de la photothèque doivent rester une solution de dernier recours, avec une sauvegarde récente, et non devenir une opération de maintenance courante.

Rendez prévisibles les permissions des nouveaux fichiers

Les fichiers existants peuvent sembler parfaits alors que les nouveaux fichiers dérivent immédiatement parce que les règles de création sont incorrectes. Vérifiez l’ACL du répertoire parent, les entrées d’ACL par défaut, l’umask, l’identité du service ainsi que les paramètres de création SMB ou NFS qui s’appliquent au chemin. L’objectif de prévention est l’héritage, pas le nettoyage.

Avant de modifier récursivement les modes, comparez la propriété numérique sur l’hôte avec l’UID/GID utilisé réellement dans le conteneur. Cette vérification de l’UID/GID d’un bind mount permet rapidement de distinguer une incompatibilité d’identité d’une permission réellement manquante. Corrigez la relation entre le propriétaire et le groupe au lieu de la masquer avec des modes trop permissifs.

Créez un petit fichier de test par chaque chemin d’écriture normal : téléversement Immich, workflow d’importation, transfert SMB/NFS s’il est utilisé et restauration d’une sauvegarde. Examinez le propriétaire, le groupe, le mode et l’ACL après chaque test. Si deux chemins de création produisent des résultats incompatibles, résolvez ce conflit de règles avant d’importer davantage de données.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Empêchez les modifications des points de montage et les mises à jour de réécrire la propriété

Considérez toute modification de Compose, mise à jour d’image, reconnexion d’un NAS ou migration comme une opération sensible aux permissions. Avant de l’appliquer, notez la source et la destination actuelles du montage, indiquez si le chemin est en lecture seule ou en lecture-écriture, relevez l’utilisateur effectif du conteneur et prélevez un échantillon de la propriété numérique de chaque répertoire important.

Les transferts et le stockage réseau peuvent introduire des identités SMB/NFS différentes, des identifiants numériques différents, un héritage d’ACL différent et un comportement d’umask différent. Utilisez les points de défaillance liés aux changements de permissions sur un NAS comme liste de contrôle avant toute modification lorsque les données Immich passent d’un système de fichiers ou d’une méthode d’accès à un autre.

Après la modification, comparez les mêmes échantillons avant d’exécuter des tâches en masse. Si la propriété change soudainement au démarrage, arrêtez la pile et déterminez quelle instruction d’entrée, tâche de maintenance ou identité remappée en est la cause. Ne laissez pas une réécriture récursive inexpliquée de la propriété se poursuivre sur une grande bibliothèque.

Auditez la dérive à l’aide de tests courts et répétables

Effectuez un audit léger des permissions selon un calendrier défini ou après les mises à jour : vérifiez quelques originaux stables, un téléversement récent, un dérivé nouvellement généré et tout montage de bibliothèque externe. Recherchez les propriétaires inattendus, l’absence d’accès au groupe, les montages en lecture seule devenus accessibles en écriture ou les ACL qui ne sont plus héritées comme prévu.

Effectuez ensuite un test d’écriture de bout en bout. Téléversez un fichier de test par l’intermédiaire du client habituel, laissez Immich le traiter, ouvrez-le, puis supprimez-le depuis l’application. Si les bibliothèques externes ou les chemins d’importation font partie de votre configuration, ajoutez un fichier représentatif par ces chemins et vérifiez qu’Immich peut le lire sans modifier la propriété de manière inattendue.

La boucle de prévention n’est complète que lorsque les nouveaux fichiers continuent de recevoir l’identité et les accès prévus après un redémarrage d’Immich et un redémarrage de l’hôte. Si les permissions nécessitent une réparation manuelle après l’un ou l’autre de ces événements, le système dérive toujours ; corrigez la règle de création ou la correspondance des identités avant d’élargir les accès.