Un refus d’accès sous Linux ne vient pas toujours d’un chmod oublié. La commande qui échoue peut tourner avec un autre UID, ou son compte n’appartient pas au groupe attendu. Avant de modifier un propriétaire, commencez par identifier le compte réellement utilisé.
La commande id affiche l’UID, le groupe principal et les groupes secondaires du processus courant. C’est le point de départ quand un script, un service ou une session SSH ne voit pas le même fichier que vous.

Lire l’UID, le GID et les groupes avec id
Lancez id sans argument dans la session qui pose problème :
id
Une sortie comme uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo),999(docker) décrit l’identité du processus. uid est l’identifiant utilisateur. gid est le groupe principal. groups ajoute les groupes secondaires, souvent ceux qui ouvrent un accès à Docker, aux journaux ou à un partage.
Pour ne récupérer qu’une valeur, utilisez les options suivantes :
id -uaffiche l’UID effectif.id -gaffiche le GID effectif.id -Gnliste les noms des groupes.id -unaffiche le nom du compte effectif.
La différence entre identifiant réel et effectif apparaît surtout après sudo, dans un binaire SUID ou avec certains outils qui changent d’utilisateur. Pour une vérification rapide du nom seul, consultez aussi notre article sur whoami et l’utilisateur effectif.
Inspecter un compte sans ouvrir sa session
Ajoutez le nom du compte pour interroger sa fiche locale. Cette commande lit la base utilisateurs et ne vous connecte pas sous ce compte :
id www-data
id -Gn www-data
Sur Debian et Ubuntu, www-data est souvent le compte des services web. Sur une autre distribution, le service peut utiliser apache, nginx ou un compte applicatif. Vérifiez le fichier d’unité ou la configuration du service au lieu de reprendre cet exemple tel quel.
Après avoir ajouté un utilisateur à un groupe, une session déjà ouverte peut conserver son ancienne liste de groupes. Déconnectez-vous puis reconnectez-vous avant de conclure que la modification a échoué. La commande id utilisateur relit la base, mais id seul décrit toujours votre processus actuel.
Comparer l’identité du compte et les droits du fichier
Connaître les groupes ne suffit pas. Il faut ensuite lire le propriétaire, le groupe et les permissions du chemin concerné :
id
stat -c '%U %G %A %n' /chemin/vers/le/fichier
namei -l /chemin/vers/le/fichier
stat indique à qui appartient le fichier. namei -l affiche aussi les droits de chaque répertoire du chemin. Un fichier lisible ne sert à rien si le compte ne peut pas traverser le dossier parent, ce qui demande le droit x sur ce répertoire.
Ne corrigez pas un refus avec chmod 777. Comparez d’abord le groupe du fichier avec id -Gn, puis ajustez le propriétaire, le groupe ou les droits nécessaires. Pour revoir les groupes et leurs usages, lisez la gestion des groupes sous Linux. Si vous devez modifier les permissions, notre guide sur chmod récursif explique pourquoi une commande trop large peut toucher bien plus de fichiers que prévu.
Tester sous le compte concerné avant de modifier sudo
Quand vous avez les droits d’administration, exécutez uniquement le contrôle sous le compte qui rencontre le problème :
sudo -u www-data id
sudo -u www-data test -r /chemin/vers/le/fichier && echo lisible
sudo -u www-data test -x /chemin/vers/le/dossier && echo traversable
Le premier appel confirme l’identité effective. Les deux suivants répondent à une question précise, lecture du fichier ou traversée du dossier. Remplacez www-data et les chemins avant exécution. N’utilisez pas sudo -u pour lancer une application de production juste afin de tester ses droits.
Si l’accès reste refusé alors que UID, groupe et permissions Unix semblent corrects, vérifiez aussi les ACL avec getfacl, les montages réseau et SELinux ou AppArmor selon votre distribution. Ces mécanismes peuvent ajouter une règle au-dessus des droits classiques.
Avec id, stat et un test sous le bon compte, vous savez où chercher avant de modifier des droits à l’aveugle.