Comment configurer les identifiants utilisateur des conteneurs sur plusieurs partages NAS

Configurez les identifiants utilisateur des conteneurs sur plusieurs partages NAS en associant l’identité numérique réelle de chaque processus de conteneur au propriétaire, au groupe, à l’ACL et au mode de montage de chaque partage dont il a besoin.

Ne forcez pas un seul UID à être propriétaire de tous les jeux de données et n’utilisez pas chmod 777 comme stratégie d’intégration. Un serveur multimédia peut avoir besoin d’un accès en lecture seule aux photos, un outil de téléchargement peut nécessiter un accès en lecture/écriture à un partage d’importation, et un conteneur de sauvegarde peut avoir besoin d’une autre destination protégée. Utilisez la propriété pour la responsabilité principale, et les groupes ou les ACL pour les accès partagés.

Enregistrez les trois identités avant de modifier les permissions

Pour chaque service, notez l’UID/GID du propriétaire côté NAS, l’utilisateur numérique et les groupes du processus à l’intérieur du conteneur, ainsi que toute convention d’identité propre à l’image, comme PUID/PGID. Ces trois valeurs sont souvent confondues, car les noms d’utilisateur peuvent sembler identiques alors que les identifiants numériques diffèrent.

Une explication actuelle de PUID et PGID précise la distinction : PUID et PGID sont des variables interprétées par certaines images de conteneurs, et non des paramètres Docker universels.

Vérifiez le processus en cours avec id dans le conteneur et inspectez les fichiers de l’hôte avec leur propriété numérique. Ne supposez pas que les valeurs indiquées dans Compose contrôlent réellement le processus, sauf si l’image prend en charge cette méthode.

Utilisez un propriétaire principal et des groupes partagés pour les données interservices

Un partage utilisé par une seule application peut avoir un propriétaire dédié. Un partage sur lequel plusieurs services écrivent est généralement plus facile à gérer avec un groupe partagé défini volontairement ou une ACL accordant uniquement les opérations nécessaires à ces services.

Une explication pratique de la propriété fondée sur des UID et GID numériques montre pourquoi les fichiers montés en liaison suivent la propriété numérique de l’hôte et pourquoi faire correspondre ces identifiants, ou les mapper délibérément, permet d’éviter les fichiers créés par root et les échecs de permission.

Dans un flux multimédia, par exemple, l’outil de téléchargement peut être propriétaire de ses fichiers temporaires, tandis que l’outil de téléchargement et l’organiseur appartiennent tous deux à un groupe media. Configurez l’héritage des répertoires, les ACL par défaut ou un comportement umask approprié afin que les nouveaux fichiers conservent automatiquement l’accès partagé.

Accordez à chaque partage uniquement les droits de montage nécessaires au conteneur

L’identité n’est qu’une couche. Même avec un UID correctement mappé, un conteneur ne peut pas écrire via un montage en liaison en lecture seule, et un conteneur disposant de permissions étendues sur le système de fichiers peut tout de même être limité de manière sûre en montant une bibliothèque en lecture seule.

Une explication des remplacements de l’utilisateur d’exécution publiée en 2026 décrit l’utilisation de la propriété de l’hôte par les montages en liaison et explique comment les paramètres d’exécution user: peuvent aligner les identifiants des processus, tout en avertissant que forcer un utilisateur peut perturber les images dont la logique de démarrage attend des privilèges différents.

Documentez chaque chemin de l’hôte, chemin du conteneur, mode de montage, opération requise et service responsable. Utilisez des montages en lecture seule pour les bibliothèques qu’un service ne fait que consulter et réservez l’accès en écriture au chemin le plus restreint qui en a réellement besoin.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gérez délibérément les différents modèles d’ACL des NAS

Les ACL SMB/NFSv4, les ACL POSIX, le mappage des identités NFS et les simples bits de mode Unix peuvent présenter des vues différentes des accès. Un partage qui fonctionne via SMB avec un utilisateur NAS donné peut tout de même refuser un processus de conteneur utilisant une autre identité numérique sur l’hôte.

L’article connexe de ZimaSpace sur les modifications des permissions NAS montre pourquoi l’héritage des ACL de destination, l’identité SMB, l’UID/GID du conteneur et l’umask doivent être diagnostiqués comme des couches distinctes.

Lorsque plusieurs protocoles accèdent au même jeu de données, choisissez un modèle de permissions et documentez-le. Mélanger à répétition les modifications d’ACL dans l’interface du NAS avec des commandes shell chmod et chown peut faire en sorte que le fichier suivant se comporte différemment du précédent.

Testez la création de fichiers depuis chaque service écrivain avant toute application récursive

Créez un répertoire de test temporaire avec la propriété et l’ACL prévues. Depuis chaque conteneur, testez l’affichage de la liste, la lecture, la création, le renommage et la suppression, en limitant les tests aux opérations requises par le service. Inspectez ensuite depuis le NAS le propriétaire numérique, le groupe, le mode et l’ACL héritée du nouveau fichier.

Si les anciens fichiers fonctionnent mais que les nouveaux échouent pour un autre service, corrigez le chemin de création : appartenance au groupe, ACL par défaut, umask ou mode de fichier propre à l’application. Réparer récursivement les anciennes données n’empêche pas la même incohérence de réapparaître demain.

Ne déployez en production qu’après avoir vérifié que chaque service écrivain crée des fichiers utilisables par le service suivant requis, sans permissions élevées. Une conception UID/GID propre est récupérable parce que le mappage est documenté et reproductible, et non parce que tous les conteneurs s’exécutent par hasard avec le même utilisateur.