À quoi servent PUID et PGID dans Docker Compose ?

Ce que sont réellement PUID et PGID

PUID et PGID sont deux variables d’environnement que certaines images de conteneur lisent au démarrage. Docker lui-même ne les consulte jamais. Il s’agit d’une convention utilisée par les images linuxserver.io et quelques autres. Une image qui n’a pas été conçue pour les lire les ignore silencieusement.

Dans une image linuxserver.io, un utilisateur appelé abc est créé lors de la construction, avec l’UID (identifiant utilisateur) 911 et le GID (identifiant de groupe) 911. Le conteneur démarre en tant que root, exécute ses scripts d’initialisation, puis l’un de ces scripts modifie les identifiants de cet utilisateur avant le démarrage de l’application :

groupmod -o -g "${PGID}" abc
usermod -o -u "${PUID}" abc

L’option -o autorise l’utilisation d’un identifiant déjà utilisé ailleurs. Ensuite, le script d’initialisation abandonne les privilèges root et exécute l’application en tant que abc. Docker transmet donc PUID=1000 au conteneur comme n’importe quelle autre variable d’environnement et n’agit jamais sur cette variable. Celle-ci modifie les identifiants d’un utilisateur dans le conteneur avant le démarrage de l’application. Ainsi, avec un daemon rootful standard sans remappage des user namespaces, les nouveaux fichiers sont normalement créés sur votre disque avec l’utilisateur 1000 comme propriétaire. L’écriture dans un fichier existant et accessible en écriture ne change pas son propriétaire. Rootless Docker décale cet identifiant, comme expliqué plus loin. Si vous ne définissez pas PUID, abc conserve l’identifiant 911. C’est pourquoi un bind mount non configuré se remplit de fichiers appartenant à 911:911.

Obtenez vos deux identifiants avec id

Exécutez cette commande sur l’hôte, avec l’utilisateur propriétaire des répertoires de données :

id

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo),988(docker)

uid est votre PUID et gid votre PGID. Dans un script, id -u et id -g affichent uniquement les identifiants numériques. Sur la plupart des images VPS neuves, le premier compte utilisateur est 1000:1000, mais ne partez pas de cette hypothèse. L’attribution dépend des comptes et de la configuration présents : un serveur reconstruit peut attribuer de nouveau 1000, tandis qu’un compte créé ultérieurement reçoit un identifiant disponible plus élevé. Si vos services s’exécutent avec un compte de service dédié plutôt qu’avec votre propre compte de connexion, exécutez id thatuser et récupérez les identifiants à cet endroit.

Pourquoi vos fichiers apparaissent avec l’UID et le GID 911:911

ls -l affiche un identifiant numérique au lieu d’un nom lorsqu’aucun compte de l’hôte ne correspond à cet identifiant. Si aucun compte de l’hôte ne correspond à l’UID 911, aucun nom ne peut être affiché. Utilisez ls -ln pour afficher systématiquement les identifiants numériques et lever toute ambiguïté :

ls -ln /srv/appdata/sonarr

drwxr-xr-x 2 911 911 4096 Aug  7 09:12 Backups
-rw-r--r-- 1 911 911  512 Aug  7 09:12 config.xml

Cette sortie correspond aux valeurs par défaut intégrées au conteneur, mais la présence de fichiers existants ne suffit pas à prouver quel utilisateur exécute actuellement l’application. Le fichier config.xml de cette liste contient également les paramètres d’authentification. Cela compte lorsque vous ouvrez l’interface web pour la première fois et constatez que Sonarr et Radarr sont fournis sans nom d’utilisateur ni mot de passe par défaut. Vérifiez-le depuis l’intérieur du conteneur au lieu de supposer :

docker exec sonarr id abc
docker compose logs sonarr | head -n 25

L’init de linuxserver affiche son résultat dans le journal de démarrage, sur 2 lignes :

User UID:    911
User GID:    911

Si ces lignes indiquent 911 après que vous avez défini PUID=1000 dans votre fichier Compose, le conteneur en cours d’exécution n’utilise pas la valeur définie. La cause habituelle est d’avoir modifié docker-compose.yml, puis exécuté docker compose restart, qui réutilise le conteneur existant avec son environnement d’origine. Les changements d’environnement nécessitent docker compose up -d, qui recrée le conteneur. L’autre cause est intentionnelle : lorsqu’une image s’exécute en mode read-only ou non-root, l’init ignore entièrement la renumérotation, même si la variable est présente dans le conteneur. En mode read-only, la bannière indique l’identifiant inchangé de abc ; en mode non-root, elle indique le propriétaire de /run.

Pourquoi vous ne pouvez pas supprimer un fichier écrit par le conteneur

Le kernel compare des numéros, jamais des noms. Votre shell s’exécute avec l’UID 1000. Le fichier appartient à l’UID 911. Le répertoire qui le contient est drwxr-xr-x et appartient également à 911. Le groupe et les autres utilisateurs disposent donc des permissions de lecture et d’exécution, mais pas d’écriture. Pour supprimer un fichier, vous devez disposer de la permission d’écriture sur son répertoire, pas sur le fichier lui-même. Vous obtenez donc cette erreur même lorsque le fichier semble inoffensif :

rm: cannot remove '/srv/appdata/sonarr/config.xml': Permission denied

Un conteneur qui écrit rencontre le même problème dans l’autre sens. Si le répertoire de l’hôte appartient à votre utilisateur avec le mode 755 et que l’application s’exécute avec l’UID 911, sa première écriture échoue avec Permission denied et l’application le signale avec ses propres termes. Dans une application .NET comme Sonarr ou Radarr, cela apparaît sous la forme UnauthorizedAccessException: Access to the path '/data/downloads' is denied. La chaîne de permissions placée devant le fichier vous indique lequel des trois ensembles de permissions s’applique réellement à votre utilisateur. Lire correctement drwxr-xr-x permet de comprendre immédiatement cette erreur.

Il s’agit spécifiquement d’un problème de bind mount. Lorsque Docker crée un named volume vide et le monte sur un chemin qui existe dans l’image, il copie le contenu de ce chemin dans le volume, y compris le propriétaire et les bits de permission. L’application trouve donc un répertoire dont elle est déjà propriétaire. Un bind mount ne bénéficie pas de ce traitement : Docker monte le répertoire de l’hôte exactement tel qu’il est. Cette différence explique notamment pourquoi il est utile de savoir quand un bind mount est préférable à un named volume et quand il ne l’est pas.

Corriger un répertoire dont les permissions sont déjà incorrectes

La définition de PUID et PGID modifie le fonctionnement de l’application à partir de maintenant. Elle ne corrige pas rétroactivement tous les fichiers déjà présents sur le disque, même si le script d’initialisation corrige la propriété sur certains chemins décrits ci-dessous. Arrêtez la stack, corrigez vous-même la propriété, puis redémarrez-la :

docker compose down
sudo chown -R 1000:1000 /srv/appdata/sonarr
docker compose up -d

Utilisez sudo chown -R "$(id -u):$(id -g)" /srv/appdata/sonarr si vous préférez ne pas saisir les nombres. Effectuez cette opération lorsque le conteneur est arrêté, car une application en cours d’écriture pendant un chown récursif peut laisser une arborescence partiellement corrigée et provoquer une nouvelle série d’erreurs difficiles à comprendre.

Ce que PUID et PGID ne corrigent pas

Voici la partie qui concerne les personnes ayant pourtant tout configuré correctement. Le script de configuration des utilisateurs de l’image de base linuxserver modifie le propriétaire de trois chemins au démarrage : /app, /config et /defaults. Vos montages de médias n’en font pas partie. /data, /downloads et /tv sont transmis à l’application sans modification. Si le côté hôte de ces montages appartient à un utilisateur auquel l’utilisateur du conteneur ne peut pas écrire, le conteneur démarre correctement, affiche le bon UID dans sa bannière, puis échoue lors du premier import.

C’est le comportement attendu. Exécuter un chown récursif sur une bibliothèque de médias de douze téraoctets à chaque démarrage du conteneur serait désastreux. Cela signifie que la gestion des répertoires de médias vous incombe. Ce sont aussi les montages sur lesquels les problèmes de permissions surviennent réellement. Comme ce type d’échec n’apparaît souvent dans le journal de l’application que plusieurs heures après que le conteneur semble fonctionner correctement, un test d’écriture périodique relié à ntfy sur votre propre VPS, qui envoie des alertes sur votre téléphone permet de le détecter à peu de frais, avant qu’une semaine d’épisodes manquants ne vous en informe.

Trois façons de contrôler l’utilisateur, et dans quels cas les utiliser

Variables d’environnement PUID et PGID

Cette méthode fonctionne uniquement avec les images dont l’entrypoint lit ces variables. Elle est populaire, car le conteneur démarre toujours en tant que root, effectue sa configuration, corrige /config, puis abandonne les privilèges. Les Docker Mods et les scripts d’initialisation personnalisés continuent de fonctionner. En contrepartie, vous faites confiance à une convention plutôt qu’à une fonctionnalité de la plateforme, et les noms des variables ne sont pas standardisés d’un projet à l’autre.

La clé user: dans Compose

Il s’agit d’une véritable fonctionnalité Docker. Elle fonctionne avec toutes les images, car le runtime du conteneur l’applique avant l’exécution du code de l’image :

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    user: "1000:1000"

Le processus ne s’exécute jamais en tant que root, même momentanément. C’est un réel gain de sécurité. En revanche, cette méthode casse tout ce qui nécessite les privilèges root dans l’entrypoint. Sur les images linuxserver, le projet prend cette configuration en charge dans la mesure du raisonnable, et uniquement pour les images qu’il a testées. Les restrictions sont précises : PUID et PGID n’ont plus aucun effet, les Docker Mods ne s’exécutent pas, les services personnalisés ne s’exécutent pas, et vous devez gérer les permissions de chaque volume monté. Le modèle documenté associe cette option à un /run accessible en écriture :

user: 1000:1000
tmpfs:
  - /run:uid=1000,gid=1000,exec
security_opt:
  - no-new-privileges=true

Un effet secondaire purement esthétique surprend souvent. Un user: numérique qui ne possède aucune entrée correspondante dans le /etc/passwd du conteneur fait afficher whoami: cannot find name for user ID 1000 par les outils utilisés dans le conteneur. L’ID est valide et l’accès aux fichiers fonctionne normalement. Seule la résolution du nom échoue.

Docker rootless

Docker rootless exécute le daemon lui-même avec votre utilisateur non privilégié. Le daemon et les conteneurs s’exécutent donc sans privilèges root sur l’hôte. Le calcul des propriétaires est entièrement différent. L’UID 0 du conteneur correspond à l’UID de l’utilisateur qui exécute Docker rootless sur l’hôte. L’UID du conteneur n, pour tout n supérieur ou égal à 1, correspond à subuid + (n - 1), où subuid désigne le début de la plage qui vous est attribuée dans /etc/subuid. Les GID suivent la même règle avec /etc/subgid. Docker y attend au moins 65,536 IDs secondaires.

Relisez cette correspondance, car elle inverse les recommandations habituelles. Avec Docker rootless, un conteneur qui crée un fichier en tant que root produit normalement un fichier dont vous êtes propriétaire. Un conteneur qui crée un fichier avec l’UID 1000 produit normalement un fichier appartenant à un ID secondaire, par exemple 100999 lorsque la plage commence à 100000. L’accès depuis votre shell dépend des permissions et des ACL. La suppression dépend normalement du répertoire parent : vous pouvez donc supprimer ce fichier depuis un répertoire que vous contrôlez. La valeur PUID correcte avec un daemon rootful est donc incorrecte ici. Ces deux mécanismes modifient les propriétaires à des niveaux différents. Les utiliser ensemble sans vérification peut vous empêcher d’écrire dans les données montées. Si vous passez à rootless, vérifiez le propriétaire d’un fichier créé sur votre propre serveur avant d’y migrer une bibliothèque.

Pour la plupart des stacks auto-hébergées sur un VPS unique, utiliser PUID et PGID avec un daemon rootful est le choix pragmatique. C’est la configuration pour laquelle les images sont conçues et documentées. Utilisez user: lorsque le README de l’image indique que celle-ci a été testée avec cette option, ou lorsque vous exécutez une image officielle en amont qui ne prend pas du tout PUID en charge. Un espace de travail documentaire tel que une instance AFFiNE auto-hébergée sur un seul VPS relève du second cas, car aucun de ses conteneurs ne lit PUID. Le propriétaire de son répertoire de base de données et de ses fichiers importés est donc défini par le runtime, et non par une variable du bloc d’environnement. Il en va de même pour un centre de support Chatwoot auto-hébergé : le conteneur Rails et son worker Sidekiq écrivent tous deux dans un même répertoire d’imports, et aucun des deux ne lit PUID. Ce répertoire doit donc correspondre à l’utilisateur avec lequel l’image s’exécute déjà. Cela ne change pas non plus avec une stack plus récente. Ainsi, donner à chaque membre de l’équipe son propre agent OneCLI isolé laisse les répertoires de travail individuels et le répertoire de données Postgres appartenir à l’utilisateur utilisé par chaque image. Il s’agit donc d’un problème de user: et de chown, et non d’un problème de PUID. Placez une seule API auto-hébergée devant Codex, Claude Code et Hermes : son entrypoint gère plusieurs identités. Le conteneur doit démarrer en tant que root, la console et la passerelle s’exécutent avec un utilisateur non privilégié, et chaque session d’agent s’exécute avec son propre utilisateur. N’ajoutez pas user: à ce déploiement : son entrypoint gère le propriétaire du volume de données.

Le cas d’une stack multimédia : un groupe partagé entre les conteneurs

Une stack multimédia arr avec Sonarr, Radarr et un client de téléchargement permet de vérifier ce fonctionnement en pratique. Le client de téléchargement écrit le fichier terminé dans /data/downloads. Sonarr crée ensuite un hardlink vers ce fichier ou le déplace dans /data/media. Pour que le hardlink fonctionne, les deux conteneurs doivent avoir un accès en écriture au même arbre de répertoires. Si le client de téléchargement s’exécute avec l’UID 1000 et Sonarr avec l’UID 1001, sans droits d’écriture partagés par le groupe, l’un des deux possède les fichiers que l’autre peut seulement lire.

La solution consiste à utiliser un groupe partagé auquel chaque conteneur de la stack associe son PGID :

sudo groupadd -g 13000 media
sudo usermod -aG media deploy
sudo chown -R deploy:media /srv/media
sudo find /srv/media -type d -exec chmod 2775 {} +
sudo find /srv/media -type f -exec chmod 0664 {} +

Le 2 initial dans 2775 correspond au bit setgid. Sur un répertoire, cela signifie que chaque nouveau fichier et sous-répertoire créé à l’intérieur hérite du groupe media au lieu du groupe principal du créateur. Cette configuration reste donc valable pour les nouveaux téléchargements sans devoir réexécuter chown. Déconnectez-vous puis reconnectez-vous, ou exécutez newgrp media, avant de vérifier vos propres droits d’accès : un groupe ajouté avec usermod -aG n’apparaît pas dans une session shell déjà ouverte.

Dans le conteneur, groupmod -o -g 13000 abc renumérote le groupe abc avec le GID 13000. Ainsi, abc écrit avec le même GID que le groupe media sur l’hôte. Chaque conteneur linuxserver qui accède à cet arbre conserve son propre PUID et partage ce PGID unique. Cela inclut les conteneurs situés plus loin dans la chaîne et qui lisent seulement la bibliothèque terminée, comme Jellyfin lui-même. Un frontend comme Halcyon, qui sert cette bibliothèque comme un vidéoclub des années 90 que l’on peut parcourir, se connecte à Jellyfin en HTTP avec HALCYON_JELLYFIN_URL. Son déploiement standard ne nécessite ni le PGID partagé pour les médias ni un montage du répertoire multimédia.

Définissez ensuite UMASK=002 sur chaque conteneur linuxserver de la stack. C’est l’étape souvent oubliée. Si cette variable n’est pas définie, l’application conserve son umask hérité, sauf si un autre paramètre le modifie. La valeur d’exemple indiquée dans les README des images est UMASK=022. Avec un umask effectif de 022, une application qui demande 0666 pour un nouveau fichier obtient 0644 lorsqu’il n’existe pas d’ACL par défaut : le reste du groupe peut toujours le lire, mais ne peut pas le modifier. Cela annule la majeure partie du partage que vous venez de configurer. Avec 002 et sans ACL par défaut, une application qui demande les valeurs habituelles 0666 pour les fichiers et 0777 pour les répertoires obtient des fichiers 0664 et, dans l’arbre setgid, des répertoires 2775. Le groupe peut alors écrire. Un umask ne fait que retirer des bits. Une application qui demande 0600 obtient donc toujours 0600. En revanche, un répertoire qui possède une ACL par défaut ignore complètement le umask. Ajoutez la variable à côté de PUID et PGID :

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config
      - /srv/media:/data
    restart: unless-stopped

Ces deux valeurs doivent figurer dans un fichier .env placé à côté du fichier Compose, afin que toute la stack utilise une seule définition :

PUID=1000
PGID=13000

Compose lit automatiquement ce fichier pour la substitution de variables de type ${PUID}. Il s’agit du même mécanisme que celui utilisé pour les identifiants. Les pratiques recommandées dans la conservation des valeurs hors de docker-compose.yml, dans un fichier .env s’appliquent également ici. La différence est que ces deux nombres ne sont pas secrets.

Vérifiez le fonctionnement de bout en bout au lieu de vous fier à la configuration. Écrivez un nouveau fichier avec l’utilisateur de l’application en appliquant le umask configuré, puis lisez-le depuis l’hôte. Utilisez un nom de fichier de test qui n’existe pas déjà :

docker exec --user abc sonarr sh -c 'umask "$UMASK" && touch /data/downloads/permtest'
ls -ln /srv/media/downloads/permtest

Un résultat correct indique votre PUID comme propriétaire, 13000 comme groupe et -rw-rw-r-- comme mode. Si le groupe affiché est 1000, exécutez ls -ldn /srv/media/downloads : soit le bit setgid, le s dans drwxrwsr-x, manque sur ce répertoire, soit le répertoire appartient encore au groupe 1000 au lieu de media. Les commandes chown et chmod 2775 ci-dessus corrigent ces deux problèmes. Si le mode affiché est -rw-r--r--, vérifiez la valeur UMASK du conteneur et l’ACL par défaut du répertoire. Recréez le conteneur si son environnement n’est plus à jour. Ce test vérifie la création avec abc et le masque configuré. Le mode de création demandé par l’application et son umask effectif déterminent toujours les droits de ses fichiers. Supprimez le fichier de test avec rm /srv/media/downloads/permtest lorsque vous avez terminé.

Quelles images utilisent quelles variables

Les images linuxserver.io utilisent PUID, PGID et UMASK. Paperless-ngx utilise d’autres noms pour le même principe : USERMAP_UID et USERMAP_GID, qui valent tous deux 1000 par défaut. Sa documentation vous indique de les lire depuis id -u et id -g. Les serveurs photo présentent la même diversité : PhotoPrism possède sa propre paire PHOTOPRISM_UID et PHOTOPRISM_GID, tandis qu’Immich ne fournit aucun équivalent et laisse Docker utiliser sa clé user: pour l’utilisateur du conteneur. Choisir entre PhotoPrism et Immich détermine donc aussi le mécanisme que vous devrez maintenir pour la plus grande bibliothèque de la machine. De nombreuses images officielles en amont, notamment les images courantes de bases de données et de serveurs web, utilisent un utilisateur intégré fixe et attendent que vous définissiez user: ou que vous le laissiez tel quel. Les petits déploiements d’une seule application posent la même question. Lorsque vous installez un outil de suivi des entraînements openGym auto-hébergé, vérifiez donc sous quel utilisateur son conteneur s’exécute réellement avant de lui attribuer un bind mount. Le répertoire qui contient sa base de données dépend de cette configuration, que vous définissiez ou non PUID. Le même principe s’applique à un relais d’accès distant. Lorsque vous exécutez votre propre serveur relais RustDesk, la paire de clés Ed25519 que hbbs écrit au premier démarrage apparaît dans votre bind mount avec les droits de l’utilisateur utilisé en dernier par cette image. Vous pouvez corriger cela ensuite avec un chown exécuté côté hôte, ou choisir l’identité dès le départ avec la clé user:, car cette image ne définit aucun utilisateur par elle-même, à condition que le répertoire monté soit accessible en écriture pour l’ID choisi. Le même principe s’applique aux composants d’infrastructure que vous ajoutez plus tard. Placer Authentik devant vos applications pour utiliser une authentification unique signifie donc exécuter les images officielles authentik et Postgres, qui ne lisent aucune variable PUID. Les droits des volumes dépendent des utilisateurs sous lesquels leurs processus s’exécutent et de la configuration effectuée par leurs entrypoints. Authentik a supprimé sa dépendance à Redis dans la release 2025.10.

Consultez donc le README de chaque image avant de copier un bloc d’environnement d’un projet à un autre. Docker transmet toute variable d’environnement que vous définissez à n’importe quel conteneur, qu’un processus interne la lise ou non. Un PUID qu’aucun composant ne consomme ne produit aucune erreur, aucun avertissement et aucun effet. Le conteneur démarre avec l’utilisateur sélectionné par le paramètre user: de Docker ou par le Dockerfile. Son entrypoint peut ensuite réduire les privilèges avant de démarrer l’application. Faites cette vérification avant d’ajouter quoi que ce soit à la machine, notamment une stack auto-hébergée de scan de sécurité open-kritt. Le fichier Compose vous indique si les images prennent en charge PUID ou si les droits des répertoires que vous montez sont imposés par les images elles-mêmes.

FAQ

Pourquoi mes fichiers Docker appartiennent-ils à 911:911 ?

911 est l’UID et le GID de l’utilisateur abc intégré aux images linuxserver.io. Cette correspondance avec les valeurs par défaut intégrées est normale, mais les fichiers peuvent conserver cette propriété après la modification de PUID et PGID du conteneur. ls -l affiche les valeurs numériques brutes lorsqu’aucun compte de l’hôte ne correspond à ces ID ; aucun nom ne peut donc être affiché. Définissez PUID et PGID avec la sortie de id, recréez le conteneur avec docker compose up -d, puis corrigez les fichiers existants avec sudo chown -R 1000:1000 sur le répertoire concerné.

PUID et PGID fonctionnent-ils avec toutes les images Docker ?

Non. Ce ne sont pas des fonctionnalités de Docker, et Docker ne les lit jamais. Ils fonctionnent uniquement avec les images dont l’entrypoint les lit et appelle usermod et groupmod avant de démarrer l’application. C’est le cas de la famille linuxserver.io et de quelques projets qui ont repris ce modèle. D’autres projets utilisent d’autres noms, comme USERMAP_UID et USERMAP_GID dans paperless-ngx. Avec une image qui ne lit aucune de ces variables, elles sont acceptées et ignorées sans avertissement.

Dois-je utiliser PUID et PGID ou la clé user: dans Docker Compose ?

Utilisez PUID et PGID lorsque l’image les prend en charge, car l’entrypoint s’exécute encore suffisamment longtemps avec root pour corriger /config et démarrer correctement ses propres services. Utilisez user: lorsque l’image indique qu’elle prend en charge l’utilisateur choisi ; l’absence de prise en charge de PUID ne signifie pas à elle seule que l’entrypoint fonctionne sans root. Avec une image linuxserver, la définition de user: rend PUID et PGID inactifs, empêche l’exécution de Docker Mods et des services personnalisés, et vous rend responsable des permissions de chaque volume monté.

Sonarr utilise le bon PUID, mais ne peut toujours pas déplacer les fichiers. Quel est le problème ?

Vérifiez trois éléments, dans cet ordre. Premièrement, le montage qui contient les médias : le script de configuration utilisateur de l’image de base applique chown à /app, /config et /defaults. Ainsi, /data ou /downloads conserve la propriété définie sur l’hôte. Deuxièmement, le groupe partagé : attribuez aux conteneurs qui accèdent à l’arborescence des médias le même PGID et les permissions d’écriture pour le groupe. Troisièmement, l’umask : un masque effectif de 022 produit des fichiers 0644 lorsque l’application demande 0666 et qu’aucune ACL par défaut ne s’applique. Les autres conteneurs du groupe peuvent alors les lire, mais pas les modifier. Laisser UMASK non défini ne garantit ni un masque ni un mode de fichier particulier. Définissez UMASK=002 et activez le bit setgid sur les répertoires avec chmod 2775 afin que les nouveaux fichiers héritent du groupe. Une application qui demande 0600 crée tout de même des fichiers privés, et une ACL par défaut modifie l’attribution des permissions lors de la création.