La source identifie correctement la couche réelle de propriété : lorsqu’un conteneur crée un répertoire dans un dossier ZimaOS monté, le nouveau répertoire hérite normalement de l’identité et du comportement de l’umask du processus exécuté à l’intérieur du conteneur, et non des permissions que vous espériez voir le dossier parent imposer automatiquement.
C’est pourquoi un dossier parent accessible en écriture par tous peut tout de même contenir de nouveaux sous-dossiers root:root avec les permissions 0755. Si l’application s’exécute en tant que root et utilise un umask par défaut, il est normal que les sous-dossiers appartiennent à root, sauf si l’image prend en charge PUID/PGID, un utilisateur de conteneur spécifique, l’héritage de groupe setgid, les ACL par défaut ou un autre modèle de permissions.
L’exemple source concernait un dossier de sauvegarde monté
L’utilisateur décrivait un chemin tel que :
/media/Daten/Backupoù les nouveaux sous-dossiers devenaient :
root:root
drwxr-xr-xUn utilisateur non root tel que l’UID 999 pouvait alors lire ces nouveaux sous-dossiers, mais pas y créer de fichiers.
Un dossier parent en 0777 n’impose pas la propriété des enfants
Les permissions d’écriture du dossier parent permettent au processus du conteneur de créer un enfant. Elles ne font pas automatiquement hériter à l’enfant du propriétaire ou du groupe du parent, sauf si les règles du système de fichiers et des groupes sont configurées pour cela.
L’UID/GID du créateur et l’umask du processus déterminent le résultat habituel.
Utilisez PUID/PGID uniquement si l’image du conteneur les prend en charge
De nombreuses images de type LinuxServer exposent les variables d’environnement PUID et PGID. D’autres images ignorent complètement ces variables et nécessitent le champ Docker user: ou des paramètres propres à l’application.
Les instructions actuelles d’IceWhale pour Syncthing demandent explicitement aux utilisateurs de récupérer les vrais identifiants des utilisateurs de ZimaOS avec :
id -u username
id -g usernamepuis de saisir ces valeurs dans les champs PUID/PGID de l’application.
Consultez l’exemple actuel de PUID/PGID pour ZimaOS.
L’umask contrôle les bits de permission supprimés lors de la création
Une application qui crée des répertoires avec un mode de base 0777 sous un umask courant de 022 produira des répertoires en 0755. Un flux de travail collaboratif avec un groupe peut utiliser un umask différent si l’application le prend en charge.
Ne définissez pas globalement un umask excessivement permissif pour corriger une seule application.
setgid peut aider à conserver un groupe partagé sur les nouveaux sous-dossiers
Sur les systèmes de fichiers natifs Linux, l’activation du bit setgid sur un dossier partagé peut faire hériter aux nouveaux enfants du groupe du dossier. Cela est utile lorsque plusieurs services ou utilisateurs collaborent volontairement au sein d’un même groupe.
Cela ne modifie pas l’identifiant utilisateur du processus créateur et peut ne pas fonctionner de la même manière sur les montages NTFS/exFAT qui simulent la propriété Unix au moyen d’options de montage.
Les ACL par défaut offrent un héritage plus explicite
Sur les systèmes de fichiers prenant en charge les ACL POSIX, les entrées ACL par défaut peuvent définir les permissions accordées aux nouveaux enfants. Cette approche est souvent plus propre que l’exécution répétée d’un chmod récursif après chaque tâche de sauvegarde.
Il convient de vérifier si l’interface actuelle de ZimaOS expose un flux de travail ACL complet pour le chemin de stockage concerné avant de s’appuyer sur une configuration uniquement en ligne de commande.
La source était une demande de fonctionnalité, pas un paramètre existant de ZimaOS
L’auteur demandait un contrôle global de PUID/PGID, une option d’héritage, la gestion de l’umask, la prise en charge de setgid et une interface graphique de correction récursive. Le fil de discussion ne contient aucune réponse d’IceWhale confirmant la mise en œuvre de ces fonctionnalités.
Ne présentez pas cette liste de demandes comme des options actuellement disponibles dans les paramètres.
Corrigez l’identité de l’application avant de modifier récursivement tout le disque
Si une application de sauvegarde recrée régulièrement des dossiers appartenant à root, exécuter chown -R après chaque tâche ne traite que le symptôme. Configurez d’abord correctement l’identité, le groupe et l’umask du conteneur, puis réparez uniquement l’arborescence concernée.
Les paramètres actuels des applications ZimaOS permettent d’inspecter les mappages de volumes et la configuration des applications, tandis que les variables de permission exactes dépendent de l’image.
FAQ sur la propriété des dossiers montés
Pourquoi un sous-dossier peut-il devenir root:root sous un parent accessible en écriture ?
Parce que le processus à l’intérieur du conteneur l’a créé en tant que root et que le dossier parent ne remplace pas automatiquement l’identité du créateur.
PUID et PGID fonctionnent-ils avec toutes les images Docker ?
Non. Il s’agit de conventions de variables d’environnement propres aux images, et non de variables Docker universelles.
IceWhale a-t-elle confirmé une option globale d’héritage des permissions dans la source ?
Non. Le fil de discussion est une demande de fonctionnalité sans confirmation de sa mise en œuvre.
