Pourquoi les propriétaires des fichiers des conteneurs changent-ils après la copie des données d’une application ?
Les propriétaires des fichiers d’un conteneur changent après une copie lorsque les valeurs numériques UID/GID ne sont pas conservées ou que l’environnement d’exécution de destination les remappe ou les réécrit.
Sur un NAS domestique, un même fichier peut afficher un nom d’utilisateur sur l’hôte et un autre dans un conteneur, car les droits de propriété sont enregistrés sous forme de nombres, tandis que chaque environnement résout ces nombres via une base de comptes différente. Les copies effectuées avec une interface graphique, un partage SMB, une archive, un shell root, un outil de migration ou un point d’entrée de conteneur peuvent également remplacer les droits de propriété. Commencez par diagnostiquer l’identité numérique, puis distinguez le comportement de copie, les paramètres de l’utilisateur d’exécution, les scripts de démarrage, les espaces de noms utilisateur et le mappage des systèmes de fichiers réseau avant de modifier les permissions de toute l’arborescence de données de l’application.
Comparez les UID et GID numériques avant de comparer les noms d’utilisateur
Examinez la source et la destination avec les droits de propriété numériques, et pas uniquement les noms. Notez l’UID, le GID, le mode, les ACL, les attributs étendus et le système de fichiers pour un fichier représentatif et son répertoire parent, à la fois sur l’hôte et dans le conteneur.
Les montages bind Docker exposent les fichiers de l’hôte à des processus qui peuvent utiliser une autre base d’utilisateurs. Une discussion de la communauté Docker explique pourquoi un accès fiable dépend de l’alignement des UID/GID numériques, plutôt que de la simple correspondance des noms d’utilisateur.
Si les nombres sont identiques mais que les noms affichés diffèrent, les droits de propriété n’ont peut-être pas changé du tout. Corrigez la documentation ou le mappage des comptes au lieu de réécrire récursivement les données. Si les nombres diffèrent, conservez les éléments observés et poursuivez l’analyse des étapes de copie et d’exécution.
Déterminez si la copie a conservé ou recréé les droits de propriété
Notez précisément le chemin de copie utilisé : gestionnaire de fichiers de l’hôte, cp, rsync, archive tar, client SMB/NFS, restauration de sauvegarde, commande de copie Docker ou conteneur de migration temporaire. Chaque méthode applique des valeurs par défaut différentes pour le propriétaire, le groupe, les ACL et les attributs étendus.
Une copie exécutée en tant que root peut conserver les droits de propriété numériques lorsque des options d’archivage explicites sont utilisées, tandis qu’un autre outil peut créer tous les fichiers de destination avec le compte qui effectue la copie. Un problème récent de migration de conteneur montre comment les données d’application copiées peuvent devenir illisibles lorsque l’UID de destination diffère de l’identité d’exécution de l’application.
Répétez l’opération avec un petit répertoire de test et examinez immédiatement les droits de propriété avant le démarrage de l’application. Si les valeurs sont déjà incorrectes, corrigez la méthode de copie ou les options de restauration. Si elles ne changent qu’après le démarrage, ne modifiez pas la copie et examinez le point d’entrée du conteneur.
Faites correspondre l’utilisateur d’exécution du conteneur au propriétaire du stockage sur l’hôte
Examinez l’utilisateur effectif dans le conteneur en cours d’exécution ainsi que le propriétaire numérique du répertoire de données de l’application monté. Vérifiez également user: dans Compose, les groupes supplémentaires, les variables PUID/PGID propres à la plateforme et les paramètres de compte spécifiques à l’image.
Exécuter un conteneur avec un utilisateur non root ne lui donne pas automatiquement accès à un répertoire hôte appartenant à une autre identité numérique. Un cas présenté sur le forum Docker résout le problème en faisant correspondre l’utilisateur du conteneur et les permissions de l’hôte, plutôt qu’en rendant le répertoire accessible en écriture à tout le monde.
Choisissez un modèle stable de propriété pour l’application et documentez-le dans Compose. Ajoutez uniquement les groupes nécessaires à l’accès partagé. Évitez chmod 777, car cette commande masque l’incompatibilité d’identité, affaiblit l’isolation et ne conserve pas le propriétaire prévu pour les futurs fichiers.
Vérifiez si le point d’entrée modifie les droits de propriété au démarrage
De nombreuses images démarrent brièvement en tant que root, créent les répertoires manquants, appliquent un UID/GID configuré et modifient récursivement les droits de propriété avant de réduire les privilèges. Ce comportement peut donner l’impression qu’une copie correcte se modifie d’elle-même après le premier démarrage du conteneur.
Les environnements d’exécution et les images de conteneurs peuvent également proposer un comportement de montage qui modifie les droits de propriété. Un problème Podman indique que l’option :U peut réécrire les droits de propriété de la source, tandis que les scripts de point d’entrée peuvent effectuer une modification récursive similaire au démarrage de l’application.
Démarrez le conteneur une fois avec les journaux visibles et surveillez une petite arborescence de test. Recherchez dans le point d’entrée et les notes de version de l’image les commandes chown, la migration d’utilisateurs, PUID/PGID et les étapes de correction des permissions. Désactivez ou limitez ce comportement uniquement lorsque l’image prend en charge une solution stable.
Tenez compte de Docker rootless, des espaces de noms utilisateur et des systèmes de fichiers réseau
Docker rootless et le remappage des espaces de noms utilisateur traduisent les identifiants du conteneur vers une autre plage sur l’hôte. NFS, CIFS et certaines options de montage des NAS peuvent indépendamment appliquer un squash du root ou forcer tous les fichiers à utiliser un UID et un GID configurés.
Un rapport sur les permissions de Docker rootless montre que des fichiers peuvent apparaître avec des droits de propriété inattendus, car l’identité du conteneur est mappée via une plage secondaire de l’hôte. L’indice de diagnostic est le mappage des droits de propriété de l’espace de noms utilisateur, et non un échec de copie classique.
Vérifiez si le chemin des données se trouve sur un système de fichiers local, NFS, CIFS, FUSE ou un autre système monté, puis notez son comportement concernant les UID/GID, le root squash et les ACL. Testez séparément la création de droits de propriété depuis l’hôte et depuis le conteneur. Ne lancez pas de chown récursif sur un partage réseau avant d’avoir compris la politique d’identité appliquée côté serveur.
Réparez les droits de propriété à partir d’une identité d’application connue
Arrêtez l’application, sauvegardez les métadonnées actuelles et définissez précisément l’UID, le GID, les modes des répertoires, les modes des fichiers, les ACL, ainsi que les étiquettes de sécurité attendues par l’image. Corrigez uniquement les chemins appartenant à l’application, en excluant les médias partagés et les jeux de données sans rapport.
Le guide ZimaSpace consacré à la séparation des problèmes de permissions et des montages en lecture seule constitue la prochaine vérification lorsque des droits de propriété corrects ne permettent toujours pas d’écrire.
Redémarrez le conteneur et créez, modifiez puis supprimez un fichier de test en tant que véritable utilisateur du service. Recréez ensuite le conteneur et répétez le test. La réparation est terminée uniquement lorsque les droits de propriété restent stables après une copie, un démarrage, un redémarrage et la recréation du conteneur, et que l’application peut lire et écrire sans exceptions de permissions trop larges.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
