« Accès refusé » sur vos propres fichiers après réinstallation : corriger la propriété

Ce qui se passe réellement : les noms mentent, les numéros non

La propriété des fichiers Linux est stockée sous forme d’identifiants numériques : UID (identifiant utilisateur) et GID (identifiant de groupe). La chaîne « alice » n’est qu’une recherche dans /etc/passwd (ou LDAP/SSSD). Votre fichier indique « possédé par l’UID 1001. » Votre système traduit 1001 en nom s’il le peut. Après réinstallation, « alice » peut être maintenant l’UID 1000, et 1001 peut appartenir à personne — ou pire, à un autre compte.

Donc vous vous connectez en tant que « alice », mais vos fichiers sont possédés par « UID 1001 », et votre nouvelle « alice » est UID 1000. Le noyau vérifie les numéros, pas les sentiments. Le contrôle échoue. Vous obtenez « Permission refusée. »

C’est l’histoire principale. Mais les systèmes de production ont des rebondissements :

• Les ACL peuvent outrepasser les bits classiques rwx. Vous pouvez « posséder » le fichier et être malgré tout refusé.
• Les options de montage du système de fichiers peuvent masquer ou inventer la propriété (fréquent sur FAT/NTFS/CIFS).
• Les systèmes de fichiers réseau peuvent réécrire l’identité (idmapping NFS, root squash, Kerberos).
• Les couches de chiffrement peuvent modifier qui peut ouvrir quoi (eCryptfs, fscrypt ; LUKS est généralement OK).
• SELinux/AppArmor peut dire « non » même quand les permissions disent « oui ».

Et oui, vous pouvez « réparer » ça avec chmod 777. Vous pouvez aussi réparer votre voiture en retirant les freins. Les deux approches sont rapides et éducatives.

Une citation à garder en tête quand vous êtes tenté d’écraser les permissions : « L’espoir n’est pas une stratégie. » — Gene Kranz.

Mode opératoire de diagnostic rapide (vérifiez ceci en premier)

C’est le chemin le plus rapide vers le goulot d’étranglement. Faites ceci dans l’ordre. Chaque étape vous dira si vous avez affaire à un décalage UID/GID, des ACL, des sémantiques de montage ou des couches de sécurité.

1) Confirmez que l’erreur est de permission/propriété, pas un problème de disque ou de corruption

• Si les lectures fonctionnent mais les écritures échouent : probablement propriété/ACL/montage en lecture seule.
• Si lectures et stat échouent : possiblement un problème de montage, clé de chiffrement manquante, ou corruption du système de fichiers.

2) Vérifiez qui vous êtes (numériquement) et qui possède le fichier (numériquement)

• Si votre UID diffère de l’UID du fichier : vous avez le décalage classique après réinstallation.
• Si les numéros correspondent mais que l’accès est toujours refusé : regardez les ACL, les attributs immuables, SELinux/AppArmor ou les options de montage.

3) Vérifiez le type de montage et les options

• FAT/NTFS/CIFS « imitent » souvent la propriété. Votre chown peut ne rien faire.
• NFS peut mapper les identités ; la propriété « nobody » est un indice important.
• Les montages en lecture seule surviennent après des récupérations de journal, des arrêts incorrects ou un montage explicite en ro.

4) Vérifiez les ACL et les attributs

• Les refus par ACL sont courants sur les postes d’entreprise et les répertoires d’équipe partagés.
• Le bit immuable (chattr +i) est rare mais inoubliable.

5) Ce n’est qu’ensuite que vous appliquez la correction

• Privilégiez un chown ciblé plutôt que le carpet-bombing récursif.
• Privilégiez les changements de propriété numériques quand vous migrez entre systèmes.
• Ne « réparez » pas des montages qui ne supportent pas la propriété en forçant chown ; vous perdrez du temps.

Tâches pratiques : commandes, sorties, décisions

Ci‑dessous des tâches réelles que vous pouvez exécuter. Chaque item inclut : la commande, ce que la sortie signifie, et la décision à prendre. Lancez-les depuis un shell avec les privilèges appropriés. En cas de doute, commencez en lecture seule et montez en privilèges avec précaution.

Task 1: Verify your current numeric identity

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo),118(lpadmin)

Signification : Votre compte est UID 1000, GID principal 1000. Ce sont ces numéros que le noyau utilise pour les contrôles d’accès.

Décision : Gardez ces numéros sous la main ; vous les comparerez à la propriété des fichiers.

Task 2: Inspect a failing file with numeric owners

cr0x@server:~$ ls -ln /mnt/oldhome/cr0x/Documents/report.txt
-rw------- 1 1001 1001 8421 Jan 12 09:14 /mnt/oldhome/cr0x/Documents/report.txt

Signification : Le fichier est possédé par UID 1001 et GID 1001. Votre utilisateur actuel est 1000. Ce décalage est la preuve évidente.

Décision : Prévoyez de changer la propriété de 1001:1001 vers 1000:1000 (ou vers l’utilisateur/groupe cible corrects).

Task 3: Confirm what UID 1001 maps to on this system

cr0x@server:~$ getent passwd 1001

Signification : Aucune sortie signifie que l’UID 1001 n’est attribué à aucun utilisateur sur ce système.

Décision : Sûr de réaffecter la propriété loin de 1001, en supposant que 1001 correspondait à votre ancien compte sur l’ancienne installation.

Task 4: Check the filesystem type and mount options

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/oldhome
/dev/sdb2 ext4 rw,relatime

Signification : ext4 supporte la propriété Unix et les permissions. chown fonctionnera comme prévu.

Décision : Procédez aux corrections de propriété au niveau du système de fichiers.

Task 5: Detect read-only mounts (silent permission killers)

cr0x@server:~$ mount | grep ' /mnt/oldhome '
/dev/sdb2 on /mnt/oldhome type ext4 (rw,relatime)

Signification : Il est monté en lecture‑écriture (rw). Si vous aviez vu ro, les écritures échoueraient indépendamment de la propriété.

Décision : Si ro, remontez en rw (après vérification des logs) au lieu de courir après les permissions.

Task 6: Try a non-destructive write test

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
touch: cannot touch '/mnt/oldhome/cr0x/.permtest': Permission denied

Signification : Le répertoire refuse l’écriture pour votre UID. Cela correspond au décalage de propriété.

Décision : Corriger la propriété de l’arborescence du répertoire (ou au moins des chemins inscriptibles dont vous avez besoin).

Task 7: Check directory ownership and mode (directories are the gate)

cr0x@server:~$ ls -ldn /mnt/oldhome/cr0x
drwx------ 72 1001 1001 4096 Feb  1 18:22 /mnt/oldhome/cr0x

Signification : Le répertoire est 0700 possédé par 1001. Seul l’UID 1001 peut lire/écrire/entrer.

Décision : La propriété doit changer, sinon rien à l’intérieur n’a d’importance.

Task 8: Preview what you are about to change (find by numeric UID)

cr0x@server:~$ sudo find /mnt/oldhome/cr0x -xdev -uid 1001 -maxdepth 2 -printf '%u:%g %m %p\n' | head
1001:1001 700 /mnt/oldhome/cr0x
1001:1001 700 /mnt/oldhome/cr0x/.ssh
1001:1001 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
1001:1001 644 /mnt/oldhome/cr0x/.bashrc
1001:1001 700 /mnt/oldhome/cr0x/Documents

Signification : Vous voyez l’envergure du changement. Le -xdev vous maintient sur ce système de fichiers (important si ~/ contient des montages).

Décision : Si la liste paraît correcte, procédez. Si elle inclut des chemins inattendus (comme des sauvegardes montées), arrêtez et affinez.

Task 9: Fix ownership safely (targeted, recursive, staying on one filesystem)

cr0x@server:~$ sudo chown -R --from=1001:1001 1000:1000 /mnt/oldhome/cr0x

Signification : Cela change la propriété uniquement si le propriétaire/groupe actuel correspondent à 1001:1001. Cela évite de « oups, j’ai changé les fichiers de quelqu’un d’autre ».

Décision : Utilisez --from chaque fois que vous migrez la propriété après une réinstallation. C’est une ceinture de sécurité qui marche vraiment.

Task 10: Re-test write access

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
cr0x@server:~$ ls -l /mnt/oldhome/cr0x/.permtest
-rw-r--r-- 1 cr0x cr0x 0 Feb  4 10:11 /mnt/oldhome/cr0x/.permtest

Signification : Vous pouvez écrire maintenant ; la propriété et les permissions sont alignées avec votre identité actuelle.

Décision : Supprimez le fichier de test et validez les répertoires sensibles comme .ssh.

Task 11: Verify and harden .ssh permissions (common post-fix breakage)

cr0x@server:~$ chmod 700 /mnt/oldhome/cr0x/.ssh
cr0x@server:~$ chmod 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
cr0x@server:~$ ls -ld /mnt/oldhome/cr0x/.ssh
drwx------ 2 cr0x cr0x 4096 Feb  4 10:08 /mnt/oldhome/cr0x/.ssh

Signification : SSH est pointilleux ; il attend des modes serrés. Les corrections de propriété laissent parfois des bits écriture groupe, et SSH refusera d’utiliser les clés.

Décision : Normalisez .ssh maintenant pour ne pas déboguer plus tard « Permission denied (publickey) ».

Task 12: Check for ACLs that can still deny access

cr0x@server:~$ getfacl -p /mnt/oldhome/cr0x/Documents | sed -n '1,20p'
# file: /mnt/oldhome/cr0x/Documents
# owner: cr0x
# group: cr0x
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

Signification : Pas de ACL de refus surprenante ici ; c’est essentiellement la sémantique 0700 avec des ACL par défaut pour les nouveaux fichiers.

Décision : Si vous voyez des entrées comme user:cr0x:--- ou un masque ACL restrictif, corrigez les ACL plutôt que de chmod à l’aveugle.

Task 13: If ownership “won’t change,” confirm you’re not on NTFS/FAT or CIFS

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /mnt/share
cifs rw,relatime,vers=3.1.1,cache=strict,username=cr0x,uid=1000,gid=1000,file_mode=0644,dir_mode=0755

Signification : CIFS présente la propriété via les options de montage. chown ne persistera généralement pas parce que le serveur contrôle la propriété (ou le client la simule).

Décision : Corrigez la propriété/permissions côté serveur (Samba/ACL Windows) ou ajustez les options de montage (uid=, gid=, file_mode=, dir_mode=).

Task 14: If NFS shows “nobody,” check idmapping

cr0x@server:~$ ls -ln /mnt/nfs/home/cr0x | head
drwx------  5 65534 65534 4096 Feb  3 14:20 .
drwxr-xr-x 12 65534 65534 4096 Feb  3 14:20 ..

Signification : UID/GID 65534 est typiquement « nobody/nogroup ». Votre client et serveur ne sont pas d’accord sur le mapping d’identité.

Décision : Corrigez l’idmapping NFS (mêmes UID/GID entre systèmes, ou configuration idmapd correcte, ou utilisez NFSv4 avec identités cohérentes).

Task 15: Check immutable attribute (the “why won’t chmod/chown work?” culprit)

cr0x@server:~$ lsattr -d /mnt/oldhome/cr0x/Documents
-------------e------- /mnt/oldhome/cr0x/Documents

Signification : Pas de drapeau i, donc ce n’est pas immuable. Si vous aviez vu ----i--------, les modifications seraient bloquées même en root.

Décision : Si immuable, retirez-le avec chattr -i (prudemment et seulement si justifié).

Task 16: Check SELinux denials (when everything looks right but still fails)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
type=AVC msg=audit(1707041254.332:812): avc:  denied  { write } for  pid=2419 comm="vim" name="report.txt" dev="sdb2" ino=931281 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0

Signification : SELinux refuse les écritures sur la base des étiquettes (tcontext), pas des permissions Unix.

Décision : Restaurez les contextes corrects (souvent avec restorecon) au lieu d’affaiblir les permissions Unix.

Corrections de propriété sans mettre le système en péril

La bonne correction dépend de l’endroit où résident les fichiers et de la façon dont ils ont été créés. Mais la règle d’or est constante : corriger l’identité, ne pas la masquer.

Meilleur cas : système de fichiers Linux local (ext4/xfs/btrfs)

Si vos fichiers sont sur un système de fichiers Linux standard, et que votre utilisateur a reçu un nouvel UID après réinstallation, vous avez deux options propres :

1. Changer l’UID/GID de l’utilisateur pour correspondre aux fichiers (utile si vous avez beaucoup de fichiers et voulez maintenir la stabilité numérique).
2. Changer la propriété des fichiers pour correspondre au nouvel UID/GID (utile si les affectations UID du nouveau système importent ou si vous avez plusieurs utilisateurs).

Je préfère l’option 2 pour les postes mono‑utilisateur (desktop/laptop). Je préfère l’option 1 pour les serveurs avec stockage partagé, exports NFS, ou tout ce qui tient à une identité stable entre hôtes.

Corriger les fichiers (chown) vs corriger le compte (usermod)

Option A : Changer la propriété d’un ancien répertoire personnel

Vous avez déjà vu le schéma le plus sûr : chown -R --from=OLDUID:OLDGID NEWUID:NEWGID. C’est ennuyeux et correct. C’est un compliment.

Soyez chirurgicaux :

• Utilisez -xdev avec find pour éviter de traverser des sous‑arbres montés.
• Faites une prévisualisation (find ... -uid OLDUID) avant de muter quoi que ce soit.
• Ne lancez pas un chown récursif sur /. Là gît la folie.

Option B : Faire correspondre le nouvel utilisateur à l’ancien UID/GID

Cela peut être plus propre quand le disque ancien est faisant autorité et que vous voulez continuité entre réinstallations.

cr0x@server:~$ id cr0x
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo usermod -u 1001 cr0x
cr0x@server:~$ sudo groupmod -g 1001 cr0x

Signification : Vous avez changé l’identité numérique du compte. Les fichiers existants possédés par 1000 peuvent maintenant être « orphelins » et nécessiter un chown de 1000 vers 1001 en suivi.

Décision : Ne faites cela que si 1001 est libre et que vous comprenez l’étendue des effets (services, cron, conteneurs, comptes système). C’est stable, mais ce n’est pas anodin.

Conseil opérationnel : Si c’est un système multi‑utilisateurs, coordonnez l’allocation UID/GID. Sur des flottes, utilisez une identité centralisée (LDAP/FreeIPA/AD) ou une politique stricte d’attribution d’UID. Les utilisateurs locaux ad hoc sont la source des « ça marchait sur l’ancien serveur ».

Quand chmod est le mauvais outil (la plupart du temps ici)

chmod change les bits de mode. Il ne change pas la propriété. Si vous voyez des fichiers possédés par UID 1001 alors que vous êtes UID 1000, chmod ne peut pas vous donner la propriété. Il peut accorder l’accès via groupe/autres, ce qui est parfois acceptable pour des données partagées mais est généralement une régression de sécurité pour des répertoires personnels.

Utilisez chmod pour ce pour quoi il est bon :

• Corriger des modes de répertoire cassés (bit exécution manquant sur des répertoires).
• Normaliser les modes de .ssh.
• Rendre des répertoires d’équipe en setgid pour une propriété de groupe prévisible.

Utilisez chown pour réparer « qui vous êtes ».

Cas particuliers : ACL, NFS, Samba, FAT/NTFS, ZFS, conteneurs

ACL POSIX : la couche invisible qui peut outrepasser vos attentes

Les ACL ajoutent des entrées par‑utilisateur et par‑groupe au‑delà du triplet classique propriétaire/groupe/autres. Elles introduisent aussi un masque qui peut réduire silencieusement les permissions effectives.

Douleurs typiques après réinstallation :

• Vous chown tout correctement. Vous ne pouvez toujours pas écrire. Une ACL refuse ou le masque restreint.
• Les nouveaux fichiers créés dans un répertoire héritent d’ACL par défaut que vous aviez oubliées.

Le diagnostic est simple : getfacl. La correction dépend de l’intention :

• Si les ACL sont du baggage accidentel : supprimez‑les avec setfacl -b (et peut‑être effacez les défauts avec setfacl -k).
• Si les ACL sont délibérées (répertoire partagé) : ajustez les entrées et le masque correctement.

NFS : l’identité doit correspondre des deux côtés

NFS ne fait pas en sorte que « cr0x » signifie la même chose partout. Le NFSv3 classique est majoritairement numérique. NFSv4 peut utiliser des noms avec idmapping, mais les mauvaises configurations sont courantes, surtout après une réinstallation où /etc/idmapd.conf a des valeurs par défaut différentes.

Indices que vous êtes en zone NFS :

• Les fichiers affichent UID/GID 65534 (« nobody »).
• Root ne peut pas chown à cause de restrictions côté serveur.
• Les permissions varient selon l’hôte depuis lequel vous regardez.

Stratégie de correction :

• Privilégiez une allocation UID/GID cohérente entre hôtes (identité centralisée ou politique locale stricte).
• Vérifiez les options d’export NFS et si le root squashing est actif.
• Ne « réparez » pas en faisant chmod 777 sur des exports partagés. Cela ne fait que propager le problème.

Samba/CIFS : votre UID Linux n’est pas le chef ici

Avec les partages SMB, l’accès est largement déterminé par les ACL côté serveur et l’authentification. Les options de montage client peuvent mapper la propriété pour l’affichage et les contrôles locaux, mais elles ne réécriront pas l’idée qu’a le serveur de qui peut faire quoi.

Implication : si vous ne pouvez pas accéder à des fichiers sur un partage Samba après réinstallation, ne commencez pas par chown. Commencez par :

• Les identifiants et l’appartenance au domaine
• L’héritage des ACL côté serveur
• Les options de montage (uid, gid, nounix, mfsymlinks, etc.)

FAT/NTFS : les permissions sont surtout une simulation

FAT n’a pas de concept Unix de propriété par fichier. NTFS a des ACL Windows ; les pilotes Linux peuvent les mapper, mais beaucoup de configurations utilisent un modèle de permission simplifié.

Symptômes :

• chown renvoie « Operation not permitted » ou semble fonctionner sans persistance.
• Tout apparaît possédé par l’UID/GID du montage.

Stratégie de correction :

• Définissez la propriété via les options de montage (ex. uid=1000,gid=1000).
• Choisissez un umask, fmask, dmask appropriés.
• Si vous avez besoin de véritables sémantiques Unix, copiez les données sur ext4/xfs/btrfs.

ZFS : les propriétés de dataset peuvent vous rendre fou

ZFS stocke normalement la propriété Unix, mais il a aussi des propriétés de dataset qui influencent le comportement — surtout si vous mélangez hôtes Linux, conteneurs et modes ACL différents. ACLtype et le stockage des xattr peuvent modifier la façon dont les permissions se comportent et comment les outils les rapportent.

Pour ZFS, traitez‑le comme un vrai système de fichiers de production (parce que c’en est un) :

• Vérifiez les mountpoints des datasets et que vous corrigez le bon chemin.
• Vérifiez le mode ACL si vous voyez des résultats confus.
• Ne faites pas de chown récursif à travers plusieurs datasets à moins d’être sûr.

Conteneurs et espaces utilisateurs : UID 1000 à l’intérieur n’est pas UID 1000 à l’extérieur

La réinstallation + conteneurs est là où les gens perdent des après‑midi. Avec les user namespaces, l’UID 0 d’un conteneur peut être mappé sur une plage d’UID non nulle sur l’hôte. Vos fichiers peuvent apparaître « possédés par 100000 » ou similaire sur l’hôte. Ce n’est pas une corruption ; c’est du mapping.

Point de décision :

• Si vous voulez que l’hôte et le conteneur partagent des répertoires inscriptibles, concevez le mapping intentionnellement.
• Ne chownez pas à l’aveugle des chemins hôtes pour « corriger » les permissions de conteneur ; vous pourriez casser le mapping et réduire la sécurité.

Blague #1 : Les conteneurs sont formidables jusqu’à ce que vous découvriez que votre fichier est possédé par « 100000 » et que vous commenciez à négocier avec le noyau comme s’il était un être pensant.

Trois micro-histoires d’entreprise du terrain

Micro-histoire 1 : l’incident causé par une mauvaise hypothèse

Une entreprise avait une petite flotte d’agents de build. Rien d’exotique : des VM Linux, chacune avec un SSD local pour l’espace de travail et un montage NFS pour le cache d’artefacts. Un rafraîchissement d’image courant a eu lieu après un cycle de patchs de sécurité. Nouveau système, nouvelle image de base, mêmes noms d’hôte. Tout le monde supposait que le compte utilisateur serait « le même ».

Il ne l’était pas. L’automatisation a créé l’utilisateur de build après quelques comptes système et l’a positionné sur un UID différent qu’auparavant. Localement, cela n’avait pas beaucoup d’impact — espace de travail neuf, fichiers neufs. Sur NFS, ça a compté immédiatement. Le répertoire de cache appartenait à l’ancien UID. L’utilisateur de build ne pouvait plus écrire les artefacts, donc les jobs ont commencé à échouer d’une manière qui ressemblait à des erreurs aléatoires de compilation et des timeouts. Les logs du système CI étaient pleins de bruit et presque aucun message « permission denied » parce que les outils de build réessayaient, tombaient en fallback, puis échouaient plus tard.

La réponse initiale fut prévisible : « peut‑être que NFS est capricieux. » Quelqu’un a redémarré le service client NFS. Quelqu’un d’autre a remonté le partage. Cela a acheté quelques minutes tout au plus. La panne était une dérive d’identité, pas un réseau.

La correction fut simple et légèrement humiliante : imposer un UID cohérent pour l’utilisateur de build entre les images, et chowner le répertoire de cache NFS vers cet UID/GID. La leçon fut plus précieuse que l’incident : si une ressource est partagée entre hôtes, l’identité numérique doit être traitée comme une API, pas comme une coïncidence.

Micro-histoire 2 : l’optimisation qui s’est retournée contre eux

Une organisation différente a voulu accélérer le reprovisionnement des postes de travail. Ils ont cessé de copier les répertoires personnels et les ont plutôt déplacés sur un disque secondaire qui survivrait aux réinstallations. « On le montera simplement sur /home après la réinstallation. Facile. »

C’était facile — pour les premières machines. Puis une nouvelle version d’OS a modifié le comportement de création des utilisateurs, et le premier utilisateur créé a maintenant récupéré systématiquement l’UID 1000, même quand l’équipe IT voulait un schéma de noms différent. Certaines machines ont fini avec l’ancien répertoire personnel possédé par UID 1005, le nouvel utilisateur sur UID 1000, et un environnement de bureau qui gérait le décalage en échouant de manières créatives. Boucles de connexion. Porte‑monnaie de clés cassés. Applications incapables de créer des fichiers de configuration. Les gens perdaient une demi‑journée chacun, et le support a développé une très mauvaise habitude.

Ils avaient « optimisé » en sautant une étape de migration des données, mais ils avaient aussi sauté la partie où l’on définit comment l’identité persiste dans le temps. La vraie correction fut d’intégrer une attribution prévisible d’UID/GID dans le provisionnement (ou d’utiliser une identité centralisée), et d’ajouter une étape de réconciliation des propriétés post‑installation explicite et auditée. Le processus révisé prenait quelques minutes de plus par machine. Il a évité des heures de chaos.

Blague #2 : Rien n’est plus rapide que de sauter des étapes — jusqu’à ce que vous mesuriez le temps total passé à annuler ces raccourcis ensuite.

Micro-histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise du secteur financier (qui adore les traces d’audit) gérait un environnement mixte : du bare metal, des VM, et quelques gros serveurs de fichiers. Ils avaient une règle simple et ennuyeuse : tous les utilisateurs humains provenaient d’un annuaire central, et la création locale d’utilisateurs sur les serveurs était découragée sauf justification. L’allocation UID/GID était cohérente sur chaque système Linux.

Un week‑end, ils ont dû réinstaller un nœud de traitement de données. Il avait de l’espace local scratch et montait des datasets partagés. La réinstallation s’est déroulée sans accrocs, et le nœud a rejoint le cluster sans drame. Aucune erreur de permission. Aucun chown d’urgence. Aucune propriété « nobody ». L’opérateur a dormi normalement cette nuit‑là, ce qui, dans cette profession, compte comme une victoire.

La raison n’était pas du héroïsme. C’était de la politique. L’hôte s’est reconnecté au service d’annuaire, a récupéré les mêmes identités numériques, et le stockage partagé s’est comporté comme avant. Leur gestion des changements semblait douloureusement conservatrice en temps normal. Sous contrainte, cela a payé comme une assurance.

Conclusion pratique : si vous opérez plus d’une machine, l’identité stable est de l’hygiène opérationnelle. Ce n’est pas de la bureaucratie ; c’est ce qui empêche une réinstallation de devenir une scène de crime des permissions.

Erreurs courantes (symptôme → cause → correctif)

1) « chmod 777 n’a pas réparé le problème »

Symptôme : Vous avez exécuté chmod -R 777 et vous ne pouvez toujours pas écrire, ou certaines applis échouent.

Cause racine : Décalage de propriété (UID/GID), montage en lecture seule, ACL de refus, bit immuable, ou refus SELinux/AppArmor.

Correctif : Vérifiez la propriété numérique avec ls -ln, le mode de montage avec findmnt, les ACL avec getfacl, les attributs avec lsattr, et SELinux avec ausearch. Ensuite utilisez chown ou corrigez la couche de montage/sécurité.

2) « chown: Operation not permitted » sur votre disque externe

Symptôme : chown échoue sur un disque monté.

Cause racine : Le système de fichiers ne supporte pas les sémantiques Unix de propriété (FAT), ou vous êtes sur CIFS/NTFS avec un mapping restreint.

Correctif : Utilisez les options de montage (uid=, gid=, dmask=, fmask=), ou copiez les données sur un système de fichiers natif Linux si vous avez besoin de propriétaires réels.

3) « Tout est possédé par nobody:nogroup » sur NFS

Symptôme : UID/GID affiche 65534 ; l’accès échoue.

Cause racine : Décalage d’idmapping NFS (client et serveur en désaccord), ou configuration idmap manquante/incorrecte.

Correctif : Assurez des UID/GID cohérents entre systèmes (un annuaire central aide), validez le domaine idmapping NFSv4, et remontez après les changements.

4) « Je peux lire mais pas écrire ; je possède le fichier »

Symptôme : Le propriétaire semble correct, les bits mode indiquent l’écriture, mais c’est refusé.

Cause racine : Masque ACL restrictif, système de fichiers en lecture seule, attribut immuable, ou SELinux refuse.

Correctif : getfacl pour le masque, findmnt pour ro, lsattr pour i, et vérifiez les logs SELinux/AppArmor.

5) « Après avoir corrigé la propriété, les clés SSH ont cessé de fonctionner »

Symptôme : Connexion SSH échoue avec des messages liés aux permissions.

Cause racine : Le répertoire .ssh ou les fichiers clés sont trop permissifs (écriture pour le groupe), ou la propriété est encore incorrecte.

Correctif : Assurez‑vous que ~/.ssh est 0700, les clés privées 0600, et que la propriété correspond à l’utilisateur.

6) « Ma session de bureau est coincée dans une boucle de connexion »

Symptôme : Vous vous connectez, l’écran clignote, vous revenez à l’écran de connexion.

Cause racine : Le répertoire personnel n’est pas inscriptible pour les fichiers de session (décalage de propriété), ou .Xauthority/.ICEauthority est possédé par le mauvais UID.

Correctif : Corrigez la propriété du répertoire personnel, puis supprimez/recréez les fichiers d’autorité si nécessaire.

7) « J’ai corrigé /home, mais un sous‑répertoire refuse toujours l’accès »

Symptôme : La plupart des choses fonctionnent ; un répertoire projet ne fonctionne pas.

Cause racine : Un autre UID/GID possède ce sous‑arbre, ou c’est un point de montage vers ailleurs, ou il a des ACL restrictives.

Correctif : Utilisez find ... -xdev pour éviter de traverser des montages, et inspectez le répertoire spécifique avec ls -ldn et getfacl.

Listes de contrôle / plan étape par étape

Plan A : Vous avez réinstallé Linux et monté votre ancien répertoire personnel ext4

1. Identifiez votre UID/GID actuels : id.
2. Identifiez l’ancienne propriété : ls -ldn /mnt/oldhome/you.
3. Confirmez que le système de fichiers supporte la propriété : findmnt -no FSTYPE,OPTIONS /mnt/oldhome.
4. Prévisualisez l’étendue : sudo find /mnt/oldhome/you -xdev -uid OLDUID | head.
5. Changez la propriété avec une ceinture de sécurité : sudo chown -R --from=OLDUID:OLDGID NEWUID:NEWGID /mnt/oldhome/you.
6. Retestez les écritures : touch d’un fichier temporaire.
7. Validez les permissions sensibles : normalisez .ssh.
8. Vérifiez les ACL si des anomalies persistent : getfacl.

Plan B : Stockage partagé ou plusieurs hôtes (NFS/cluster)

1. Stoppez et décidez : voulez‑vous des UID/GID stables entre hôtes ? Oui. Agissez comme tel.
2. Choisissez un UID/GID faisant autorité pour chaque compte humain/service.
3. Rendez les identités cohérentes (service d’annuaire, ou imposez une politique locale d’allocation).
4. Corrigez la propriété côté serveur quand approprié (surtout pour les exports NFS).
5. Vérifiez depuis un client : ls -ln doit afficher les propriétaires numériques attendus.
6. Verrouillez‑le : ajoutez des contrôles dans le provisionnement pour confirmer UID/GID avant de monter des chemins partagés.

Plan C : Disque externe formaté NTFS/FAT

1. Confirmez le type de système de fichiers : findmnt -no FSTYPE,OPTIONS /mnt/drive.
2. Ne vous battez pas contre chown : supposez qu’il ne persistera pas.
3. Définissez le mapping de montage : choisissez uid, gid, et des masques adaptés.
4. Si vous avez besoin de sémantiques Unix : copiez les données sur ext4/xfs/btrfs et travaillez là‑bas.

Faits intéressants et contexte historique

• Les UID/GID sont stockés sur disque en tant que nombres parce que les premiers systèmes Unix avaient besoin de contrôles compacts et rapides sans recherches de chaînes.
• Unix classique utilisait des UID 16 bits dans les implémentations anciennes ; les systèmes modernes supportent des plages beaucoup plus larges, mais des hypothèses héritées apparaissent encore dans les outils.
• L’utilisateur « nobody » est une convention utilisée pour mapper des identités inconnues ou non fiables (typiquement UID 65534), surtout dans les contextes NFS.
• Les ACL POSIX ont été ajoutées pour résoudre de vrais problèmes multi‑utilisateurs où le modèle propriétaire/groupe/autres n’était pas assez expressif pour des répertoires partagés.
• Le setgid sur les répertoires est une astuce ancienne de collaboration qui fonctionne toujours : les nouveaux fichiers héritent du groupe du répertoire, réduisant les incidents « pourquoi ce groupe est faux ? ».
• NFSv4 a introduit des sémantiques d’identité plus fortes et un fonctionnement stateful comparé à NFSv3, mais un idmapping mal configuré peut être pire qu’un comportement purement numérique.
• FAT précède les permissions Unix et n’a pas de concept de propriétaire par fichier ; Linux doit projeter un modèle de permissions au‑dessus.
• SELinux provient de la recherche en sécurité et des besoins d’entreprise pour appliquer un contrôle d’accès obligatoire au‑delà des permissions discrétionnaires Unix, d’où sa capacité à outrepasser un chmod/chown « correct ».
• Les user namespaces ont changé la donne en permettant aux conteneurs de remapper les UIDs, améliorant l’isolation mais rendant l’apparence de la propriété sur l’hôte déroutante.

FAQ

1) Pourquoi la réinstallation a‑t‑elle changé l’accès aux fichiers si mon nom d’utilisateur est identique ?

Parce que le système de fichiers stocke des UID/GID numériques, pas le nom d’utilisateur. Après réinstallation, le nom peut être mappé à un UID/GID différent, donc le noyau vous considère comme un propriétaire différent.

2) Dois‑je corriger ceci en changeant l’UID de mon nouvel utilisateur ou en chownant les fichiers ?

Si c’est une machine unique avec stockage local, chowner les fichiers vers le nouvel UID est généralement le plus simple. Si le stockage est partagé entre machines, maintenir des UID stables (et changer le compte pour correspondre) est souvent plus sûr.

3) Pourquoi chmod ne résout‑il pas « Permission refusée » dans mon cas ?

Parce que vous n’êtes pas le propriétaire (numériquement). chmod change les bits de mode, mais il ne change pas la propriété. De plus, les ACL/SELinux/montages en lecture seule peuvent toujours vous bloquer.

4) Quelle est la façon la plus sûre de faire une correction de propriété récursive ?

Utilisez chown -R --from=OLDUID:OLDGID NEWUID:NEWGID sur le répertoire spécifique, et prévisualisez avec find -uid OLDUID. Ajoutez -xdev pour éviter de traverser des points de montage lors de l’utilisation de find.

5) J’ai exécuté chown -R et maintenant quelque chose est cassé. Qu’ai‑je probablement touché ?

Victimes courantes : sous‑répertoires montés (vous avez changé la propriété d’un autre système de fichiers), répertoires d’applications qui attendent des comptes de service spécifiques, et permissions de clés SSH. Vérifiez les points de montage et revérifiez les utilisateurs de service.

6) Mes fichiers sont sur un disque NTFS. Puis‑je réparer la propriété définitivement ?

Pas au sens Unix. Vous mappez typiquement la propriété via les options de montage. Si vous avez besoin d’une propriété Unix par fichier et des modes, déplacez les données vers un système de fichiers natif Linux.

7) Pourquoi mes fichiers apparaissent‑ils possédés par « nobody » sur NFS ?

L’idmapping a échoué entre client et serveur, ou l’UID/GID est inconnu d’un côté. Corrigez en rendant les identités cohérentes ou en ajustant la configuration idmapping NFS.

8) Je possède le répertoire, mais je ne peux toujours pas écrire. Qu’est‑ce qui bloque encore ?

Montages en lecture seule, masque ACL restrictif, attributs immuables, politique SELinux/AppArmor, ou quotas. Diagnosez avec findmnt, getfacl, lsattr et les logs de sécurité.

9) Puis‑je éviter ça complètement la prochaine fois ?

Oui : gardez les UIDs stables (identité centralisée ou politique de provisionnement), documentez l’allocation UID/GID pour les comptes de service, et testez les montages et la propriété après les rebuilds avant de rendre la machine aux utilisateurs.

Conclusion : actions à entreprendre aujourd’hui

Si vous voyez « Accès refusé » sur vos propres fichiers après une réinstallation, arrêtez de le traiter comme un mystère de permissions. C’est généralement une dérive d’identité. Les numéros ont changé. Le noyau fait exactement ce qu’on lui a demandé.

Faites ceci ensuite :

1. Exécutez id et ls -ln sur un chemin en échec. Confirmez le décalage UID/GID.
2. Confirmez le type de système de fichiers et les flags de montage avec findmnt. Écartez les montages en lecture seule et ceux où la propriété est simulée.
3. Corrigez la propriété avec chown -R --from=OLDUID:OLDGID NEWUID:NEWGID sur le plus petit sous‑arbre qui a du sens.
4. Si le problème persiste, vérifiez ACL et SELinux/AppArmor avant d’entamer une « thérapie chmod ».
5. Pour les environnements partagés, faites de la cohérence UID/GID une politique, pas un espoir.

Une fois que vous aurez fait ça quelques fois, vous reconnaîtrez l’odeur en quelques secondes : même nom d’utilisateur, mauvais numéros, et un système de fichiers qui refuse poliment de se prêter à votre nostalgie.