Réparer un profil utilisateur corrompu sans perdre Bureau et Documents

février 8, 2026 • février 8, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Votre compte utilisateur « fonctionne » jusqu’à la connexion. Puis vous obtenez un bureau vide, une boucle de connexion, des Documents manquants,
ou des applications qui plantent comme si elles faisaient un speedrun. Ce n’est pas une mauvaise journée. C’est une journée de profil corrompu.

La bonne nouvelle : sur Linux, un « profil » est pour l’essentiel des fichiers — dotfiles, répertoires de configuration, et ownership/permissions.
La meilleure nouvelle : votre ~/Desktop et vos ~/Documents sont généralement des victimes innocentes. Si vous cessez d’improviser et suivez un plan,
vous pouvez réparer le compte sans anéantir les données qui comptent.

Ce que « profil utilisateur corrompu » signifie réellement sur Linux

Sur Linux, un « profil utilisateur » n’est pas une ruche de registre ni une base de données mystique. C’est votre répertoire home plus un ensemble
d’attentes : votre UID possède vos fichiers, votre shell peut lire les scripts de démarrage, votre environnement de bureau peut écrire dans
la config, et votre gestionnaire de session peut créer des fichiers temporaires.

Quand on parle de « profil corrompu », on veut généralement dire une (ou plusieurs) des situations suivantes :

Dérive d’ownership/permissions : votre home est possédé par root, ou vos dotfiles sont non modifiables.
Pression disque : home plein, épuisement d’inodes, ou quota dépassé ; les sessions échouent de façon étrange.
Config cassée : un dotfile ou un répertoire de config fait planter le shell/le bureau au démarrage.
Erreurs système de fichiers : erreurs métadonnées Ext4/XFS ; remontage en lecture seule ; erreurs I/O.
Mauvais libellé de sécurité : contextes SELinux incorrects ; la connexion réussit mais les applis ne peuvent pas lire/écrire.
Désynchronisation d’UID : même nom d’utilisateur, UID différent après une restauration ; les permissions ne suivent pas.

« Réparer » le profil signifie rétablir ces attentes tout en gardant intact ~/Desktop et ~/Documents.
Cela demande de la discipline. La manière la plus rapide de perdre des données est de commencer à « nettoyer » en supprimant des dotfolders au hasard
parce qu’un blog vous l’a conseillé.

Méthode de diagnostic rapide (premier/deuxième/troisième)

Quand vous êtes pressé, ne devinez pas. Triez comme si vous étiez de garde et privé de sommeil (parce que c’est le cas).

Premier : le système peut-il écrire où il doit ?

Est-ce que / ou /home est plein ?
Le système de fichiers est-il en lecture seule ?
L’utilisateur possède-t-il son répertoire home et les sous-répertoires clés ?

Second : est-ce un crash de session/connexion causé par la config ?

Vérifiez les logs journal pour la session utilisateur.
Essayez de vous connecter avec un nouvel utilisateur de test sur la même machine.
Essayez une session shell minimale (TTY) et voyez si le compte lui‑même est viable.

Troisième : le stockage vous ment-il ?

Scannez les erreurs I/O, relectures du journal ext4, arrêts XFS, avertissements SMART.
Cherchez l’épuisement d’inodes et les échecs de quota.
Vérifiez la cohérence des UID entre sauvegardes/restaurations.

Règle de décision : si vous voyez disque plein ou remontage en lecture seule, arrêtez d’accuser la « corruption de profil » et corrigez d’abord le stockage.
Une session de bureau qui ne peut pas écrire se comportera comme si elle était maudite.

Sécurité d’abord : préserver Desktop et Documents avant toute intervention

Vous n’avez qu’une chance de ne pas empirer la situation. Avant de « réparer », faites un snapshot ou une copie. Préférez une copie locale vers un autre
système de fichiers ou un disque externe. Si vous ne pouvez pas, au moins faites un snapshot en lecture seule (LVM/ZFS/Btrfs) ou une archive tar.

Deux règles :

N’exécutez pas de commandes destructrices dans le home de l’utilisateur tant que vous n’avez pas de sauvegarde.
N’utilisez pas « chmod -R 777 » pour régler quoi que ce soit. Ce n’est pas une solution ; c’est un générateur d’incidents.

Blague #1 : Si votre plan de récupération est « je vais juste me rappeler ce qu’il y avait dans Documents », félicitations — vous venez d’inventer la perte de données en tant que service.

Tâches pratiques (avec commandes, sorties et décisions)

Les tâches ci‑dessous supposent une distribution Linux basée sur systemd (Ubuntu, Debian, RHEL-like, Fedora, etc.) et un utilisateur nommé
alice. Ajustez les noms et chemins. Exécutez en root ou via sudo quand nécessaire.

Task 1: Confirmer que l’utilisateur existe, UID/GID et chemin home

cr0x@server:~$ getent passwd alice
alice:x:1001:1001:Alice Example:/home/alice:/bin/bash

Ce que cela signifie : UID=1001, GID=1001, répertoire home /home/alice, shell bash.

Décision : Si le chemin home est erroné ou pointe vers un répertoire non existant, corrigez cela avant toute autre chose
(problème de gestion d’utilisateur, pas de « corruption »).

Task 2: Vérifier l’espace disque et la disponibilité des inodes (les tueurs silencieux)

cr0x@server:~$ df -h / /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  420M  99% /
/dev/sda3       200G  120G   70G  64% /home

cr0x@server:~$ df -ih / /home
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.5M  2.5M     0  100% /
/dev/sda3        13M  1.2M   12M    9% /home

Ce que cela signifie : Le système racine est à 99% et épuisé en inodes à 100%. Cela peut casser les connexions car PAM,
les services systemd utilisateur et les composants du bureau ont besoin de créer des fichiers dans /run, /tmp, et des logs.

Décision : Si les octets ou les inodes sont proches/de 100% sur les montages pertinents, libérez d’abord de l’espace avant de toucher la config du profil.
La « corruption » peut disparaître dès que l’OS respire à nouveau.

Task 3: Vérifier si un système de fichiers est en lecture seule à cause d’erreurs

cr0x@server:~$ mount | egrep ' / | /home '
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sda3 on /home type ext4 (rw,relatime)

cr0x@server:~$ dmesg | tail -n 8
[12345.678901] EXT4-fs error (device sda2): ext4_find_entry:1455: inode #262210: comm systemd: reading directory lblock 0
[12345.678950] Aborting journal on device sda2-8.
[12345.679010] EXT4-fs (sda2): Remounting filesystem read-only

Ce que cela signifie : Le noyau a remonté / en lecture seule à cause d’erreurs ext4. Les sessions utilisateur échoueront de façon
étrange et incohérente.

Décision : Stoppez. Planifiez un fsck en mode maintenance, vérifiez la santé du disque, et traitez cela comme un incident de stockage d’abord.

Task 4: Chercher la défaillance dans les logs (ne pas déboguer à l’aveugle)

cr0x@server:~$ journalctl -b -p warning --no-pager | tail -n 15
... gdm-password][2100]: pam_unix(gdm-password:session): session opened for user alice(uid=1001) by (uid=0)
... systemd[2140]: Failed to create /home/alice/.cache: Permission denied
... gnome-session[2180]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
... systemd[2140]: Failed at step CHDIR spawning /usr/libexec/gnome-session-binary: Permission denied

Ce que cela signifie : La session n’arrive pas à créer ~/.cache puis le shell GNOME meurt. C’est généralement
un problème d’ownership/permissions, disque plein, ou un home monté avec de mauvaises options.

Décision : Allez directement vérifier les permissions du répertoire home et les options de montage. Réinitialiser les paramètres GNOME n’aidera pas si le système ne peut pas écrire.

Task 5: Vérifier l’ownership et le mode du répertoire home

cr0x@server:~$ ls -ld /home/alice
drwxr-xr-x 42 root root 4096 Feb  4 10:31 /home/alice

Ce que cela signifie : L’intégralité du répertoire home est possédée par root. L’utilisateur ne peut pas écrire sa propre config ou ses caches.

Décision : Corrigez l’ownership. Mais faites-le prudemment — confirmez d’abord l’UID (Task 1), puis chown.

Task 6: Corriger l’ownership en toute sécurité (ciblé, puis plus large)

cr0x@server:~$ chown alice:alice /home/alice

cr0x@server:~$ find /home/alice -maxdepth 2 -mindepth 1 -user root -print | head
/home/alice/.cache
/home/alice/.config
/home/alice/.local

cr0x@server:~$ chown -R alice:alice /home/alice/.cache /home/alice/.config /home/alice/.local

Ce que cela signifie : Vous avez corrigé le niveau supérieur et les répertoires à fort trafic d’écriture en priorité, et identifié des fichiers restants possédés par root proches de la surface.

Décision : Si l’ownership root est généralisée et légitime (par ex. restauré depuis une sauvegarde de façon incorrecte), vous pourriez devoir lancer un chown -R complet sur le home. Si le home contient des données partagées ou des montages spéciaux, arrêtez‑vous et évaluez avant les changements récursifs.

Task 7: Confirmer que l’utilisateur peut écrire aux chemins critiques

cr0x@server:~$ sudo -u alice -H bash -lc 'touch ~/.cache/profile_write_test && echo ok'
ok

Ce que cela signifie : L’utilisateur peut créer des fichiers dans ~/.cache. C’est une exigence de base pour la plupart des environnements de bureau.

Décision : Si cela échoue, vous avez encore des problèmes de permissions, de système de fichiers ou de quota. Ne passez pas à autre chose.

Task 8: Vérifier le quota (surtout en environnement d’entreprise)

cr0x@server:~$ quota -u alice
Disk quotas for user alice (uid 1001):
Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/sda3   1024000  1024000 1126400          25000   0       0

Ce que cela signifie : L’utilisateur est au quota de blocs. Les écritures échouent avec « Disk quota exceeded », souvent interprété comme « mon profil est corrompu ».

Décision : Soit augmentez le quota, soit nettoyez l’espace dans le home de l’utilisateur. Réinitialiser des dotfiles ne résoudra pas un quota dur.

Task 9: Identifier rapidement les répertoires les plus lourds (nettoyage sans vandalisme)

cr0x@server:~$ du -xhd1 /home/alice | sort -h
120M	/home/alice/.cache
2.1G	/home/alice/.local
8.4G	/home/alice/Downloads
15G	/home/alice/Documents
26G	/home/alice

Ce que cela signifie : Downloads est volumineux ; cache modeste. Documents est lourd (et doit être traité comme des données de production).

Décision : Si vous avez besoin d’espace rapidement, commencez par les caches et Downloads, pas par Documents. Envisagez aussi un nettoyage système si / est plein.

Task 10: Faire une copie de sécurité du Bureau et des Documents (préserver les métadonnées)

cr0x@server:~$ mkdir -p /root/profile-rescue/alice

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Desktop /home/alice/Documents /root/profile-rescue/alice/
sending incremental file list
Documents/
Documents/report.docx
         12,345,678 100%  112.34MB/s    0:00:00 (xfr#1, to-chk=0/3)
Desktop/
Desktop/todo.txt
             1,024 100%    0.01MB/s    0:00:00 (xfr#2, to-chk=0/2)

Ce que cela signifie : Vous avez copié les données en préservant ownership, ACLs, xattrs et hardlinks (là où c’est supporté).

Décision : Si rsync retourne des erreurs I/O, arrêtez et examinez la santé du disque. Une corruption à ce stade n’est pas une question de config de profil.

Task 11: Rechercher un fichier de config qui casse le shell (le piège .bashrc)

cr0x@server:~$ sudo -u alice -H bash --noprofile --norc -lc 'echo shell_ok'
shell_ok

cr0x@server:~$ sudo -u alice -H bash -lc 'echo shell_with_rc_ok'
bash: /home/alice/.bashrc: line 42: syntax error near unexpected token `fi'

Ce que cela signifie : Le shell fonctionne sans fichiers de démarrage, mais échoue avec .bashrc. C’est une corruption de config.

Décision : Déplacez .bashrc de côté et restaurez une version minimale connue‑bonne. Ne supprimez pas ; mettez en quarantaine.

Task 12: Mettre en quarantaine les dotfiles suspects (surgical, réversible)

cr0x@server:~$ mkdir -p /home/alice/.profile-quarantine

cr0x@server:~$ mv /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

cr0x@server:~$ cp /etc/skel/.bashrc /home/alice/.bashrc

cr0x@server:~$ chown alice:alice /home/alice/.bashrc /home/alice/.profile-quarantine/.bashrc.bad

Ce que cela signifie : Vous êtes revenu à une base par défaut tout en conservant l’ancien fichier pour inspection ultérieure.

Décision : Si cela répare les sessions terminal mais que l’interface graphique échoue toujours, le problème se situe dans la config du bureau (dconf, extensions GNOME, etc.).

Task 13: Diagnostiquer une boucle de connexion GUI en comparant avec un nouvel utilisateur

cr0x@server:~$ useradd -m -s /bin/bash testgui

cr0x@server:~$ passwd -l testgui
passwd: password changed.

Ce que cela signifie : Vous avez créé un utilisateur test (mot de passe verrouillé dans cet exemple ; en pratique vous pourriez en définir un ou utiliser des clés SSH).
L’objectif est de voir si le système peut démarrer une session de bureau pour un profil propre.

Décision : Si un nouvel utilisateur se connecte correctement mais que alice ne le fait pas, le problème est presque certainement dans le home/la config d’Alice, pas dans la pile graphique système.

Task 14: Réinitialiser les paramètres GNOME (dconf) sans toucher aux Documents

cr0x@server:~$ sudo -u alice -H bash -lc 'dconf dump / > /home/alice/.profile-quarantine/dconf-backup.ini'

cr0x@server:~$ sudo -u alice -H bash -lc 'rm -f ~/.config/dconf/user'

cr0x@server:~$ sudo -u alice -H bash -lc 'echo "dconf reset staged"'
dconf reset staged

Ce que cela signifie : Vous avez sauvegardé la base dconf et l’avez supprimée pour que GNOME recrée des valeurs par défaut.

Décision : Si GNOME démarre maintenant, votre ancienne dconf (ou une extension) était toxique. Réintroduisez les paramètres progressivement ; ne restaurez pas aveuglément.

Task 15: Corriger les XDG user dirs cassés (chemins Desktop/Documents)

cr0x@server:~$ sudo -u alice -H bash -lc 'cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktoop"
XDG_DOCUMENTS_DIR="$HOME/Documants"

cr0x@server:~$ sudo -u alice -H bash -lc 'xdg-user-dirs-update && cat ~/.config/user-dirs.dirs'
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

Ce que cela signifie : L’environnement de bureau pointait vers des répertoires mal orthographiés. Cela peut se manifester par « Bureau vide » alors que les fichiers existent.

Décision : Si les user-dirs sont incorrects, corrigez‑les et créez les répertoires manquants. Ne déplacez pas les données avant que les chemins soient corrects.

Task 16: Vérifier et réparer les contextes SELinux (si applicable)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ls -Zd /home/alice
unconfined_u:object_r:default_t:s0 /home/alice

cr0x@server:~$ restorecon -Rv /home/alice | tail -n 5
restorecon reset /home/alice context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:user_home_dir_t:s0
restorecon reset /home/alice/.ssh context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:ssh_home_t:s0

Ce que cela signifie : Les contextes étaient incorrects. SELinux peut bloquer des lectures/écritures d’une manière qui ressemble à des pannes aléatoires d’applications.

Décision : Si SELinux est en enforcing et que les contextes sont erronés, corrigez-les avant de changer les permissions. SELinux ne se laisse pas convaincre par chmod.

Task 17: Valider la santé du système de fichiers (exemple ext4)

cr0x@server:~$ smartctl -H /dev/sda
SMART overall-health self-assessment test result: PASSED

cr0x@server:~$ touch /forcefsck && echo "scheduled"
scheduled

Ce que cela signifie : SMART indique que le disque est OK (pas une garantie), et vous avez programmé un fsck au prochain démarrage.

Décision : Si vous avez vu des erreurs I/O plus tôt, vous planifiez toujours une maintenance. La corruption de profil causée par un stockage instable reviendra tant que la cause racine n’est pas corrigée.

Stratégie de reconstruction propre : nouvel utilisateur, migrer les données, réintroduire la config progressivement

Parfois la solution la plus rapide n’est pas de réparer. C’est de remplacer le profil : créer un nouvel utilisateur, copier les vraies données
(Bureau/Documents/etc.), puis ramener les paramètres sélectivement. C’est la même approche que les SRE appliquent avec l’infrastructure cattle-not-pets,
transposée au répertoire home d’un humain.

Pourquoi cela fonctionne : un profil de bureau Linux accumule de l’état. Extensions, caches, paramètres de thème, sockets obsolètes,
helpers d’authentification, saletés d’apps Electron, liens symboliques cassés, et un dotfile de dix ans que vous aviez oublié. Si vous
tentez de tout réparer sur place, vous courrez après des fantômes pendant des jours. Une migration contrôlée vous permet de stopper l’hémorragie.

Comment faire sans perdre Desktop/Documents

Créez un nouvel utilisateur (ex. alice2) avec un home propre.
Copiez d’abord uniquement les « répertoires de données » : Desktop, Documents, Pictures, etc.
Vérifiez les permissions et connectez‑vous avec le nouvel utilisateur.
Ensuite seulement, récupérez au cas par cas les répertoires de config dont vous avez vraiment besoin (clés SSH, profil navigateur éventuellement), un par un.
Conservez l’ancien home intact jusqu’à avoir vécu avec le nouveau profil au moins une semaine.

cr0x@server:~$ useradd -m -s /bin/bash alice2

cr0x@server:~$ rsync -aHAX --info=progress2 /home/alice/Documents /home/alice/Desktop /home/alice/Pictures /home/alice2/
sending incremental file list
Documents/
Desktop/
Pictures/

cr0x@server:~$ chown -R alice2:alice2 /home/alice2/Documents /home/alice2/Desktop /home/alice2/Pictures

Point de décision : Si le nouvel utilisateur fonctionne, vous avez prouvé que la pile système est correcte et que l’ancien profil était en cause. Vous pouvez alors
décider de garder le nouvel utilisateur définitivement ou de migrer de nouveau vers le nom d’utilisateur d’origine après nettoyage.

Ce qu’il ne faut pas migrer en premier

~/.cache — c’est littéralement un cache. Laissez‑le se régénérer.
~/.config en bloc — c’est là que vivent les paramètres de bureau cassés.
~/.local/share en bloc — une partie est utile (polices, données d’application), une autre est du junk. Faites du tri.
Dotfiles inconnus de 2014 — ils vous ramèneront en 2014, et pas de façon agréable.

Blague #2 : Migrer ~/.cache pour « gagner du temps » revient à emballer la poubelle de la cuisine pour « garder l’odeur ».

Particularités GNOME/KDE : dconf, caches et pourquoi votre bureau disparaît

La plupart des rapports « mon bureau a disparu » ne concernent pas un bureau qui s’évapore. Ils concernent la session de bureau qui échoue à démarrer, ou qui démarre
sans lire les bons répertoires. GNOME et KDE reposent tous deux sur un mélange de :

Répertoires home inscriptibles pour caches et état runtime.
Daemons de session gérés par des unités systemd utilisateur.
Magasins de configuration (GNOME : dconf, KDE : principalement des configs textuelles sous ~/.config).
Mappings XDG qui indiquent aux applications où sont Desktop et Documents.

GNOME : la base dconf est un point unique de « pourquoi ça arrive »

Les paramètres GNOME sont stockés dans une base binaire dconf à ~/.config/dconf/user. Si elle se corrompt,
ou contient des paramètres qui font planter GNOME Shell (souvent via des extensions), votre connexion peut boucler ou aboutir à une session brisée.

La bonne démarche est celle montrée plus haut : la sauvegarder, la supprimer, et laisser GNOME recréer les valeurs par défaut. Puis traitez les extensions
comme suspectes. Dans les images d’entreprise, les extensions sont souvent « standardisées ». Traduction : quelqu’un a touché un paramètre et maintenant c’est une politique.

KDE Plasma : la config textuelle facilite l’isolation, mais la rend aussi plus fragile

KDE stocke beaucoup de choses dans ~/.config en texte (format ini-ish). Cela facilite la recherche d’une entrée fautive et sa correction.
Mais cela facilite aussi les scripts, gestionnaires de dotfiles maladroits et outils de « durcissement » qui écrivent des configs invalides.

Si Plasma ne démarre pas, les coupables fréquents incluent des fichiers cassés comme plasmashellrc, des entrées autostart, ou
des permissions qui empêchent KDE de créer des sockets sous ~/.cache ou ~/.config.

Modes de défaillance du stockage et du système de fichiers (point de vue SRE)

Un profil utilisateur n’existe pas en dehors d’un contexte de stockage. Le stockage ment de façons intéressantes.

Disque plein n’est pas juste « plus d’espace »

Disque plein peut signifier :

Épuisement de blocs : octets utilisés, problème classique de df -h.
Épuisement d’inodes : trop de petits fichiers, surprise classique de df -i.
Épuisement de quota : l’utilisateur atteint une limite sur un filesystem partagé.

Les trois peuvent casser les connexions, navigateurs et bureaux. Ils peuvent aussi provoquer des écritures partielles de config, créant l’illusion de « corruption » plus tard.

Remontage en lecture seule : le noyau vous tapote sur l’épaule

Quand ext4 détecte des erreurs de métadonnées, il peut remonter en lecture seule pour éviter d’aggraver la situation. Les utilisateurs rapportent alors :
« Mon bureau ne sauve pas les paramètres » ou « Je ne peux pas créer de fichiers. » Ce n’est pas un problème de profil. C’est le système de fichiers qui se protège.

Homes réseau (NFS/SMB) : latence et bizarreries de cohérence

En entreprise, les répertoires home sont souvent sur NFS. Si le serveur ralentit ou si le réseau flanche, le bureau peut se bloquer pendant la connexion en attendant des dotfiles,
des keyrings ou des services D-Bus. Vous verrez des timeouts et des erreurs « stale file handle ».

Une citation opérationnelle à coller sur votre écran

Espérer n’est pas une stratégie. (idée paraphrasée, courante en ingénierie/ops)

En termes de récupération de profil : ne « espérez » pas que le bureau revienne après des suppressions aléatoires. Mesurez, copiez, mettez en quarantaine et vérifiez.

Trois mini-histoires d’entreprise tirées du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise a déployé une baseline de sécurité qui durcissait les permissions des répertoires home. Le changement était simple :
« Rendre les home non lisibles par le monde ». Sensé. L’implémentation, toutefois, supposait que chaque home vivait sur disque local et que l’ownership était cohérente.

En réalité, la moitié du parc utilisait des homes montés en réseau. Le script de baseline s’est exécuté tôt au démarrage, avant que le montage NFS
ne soit prêt. Il a donc créé volontiers /home/alice en local possédé par root (parce que le montage n’était pas là), puis l’a chmodé au nouveau mode « sécurisé ».
Dix minutes plus tard, NFS s’est monté sur /home, mais les répertoires par utilisateur étaient déjà incorrects pour certains et corrects pour d’autres, selon le timing.

Les symptômes furent chaotiques : boucles de connexion, icônes du Bureau manquantes, et applications refusant de démarrer. L’équipe a d’abord blâmé
une mise à jour GNOME parce que cela coïncidait avec le déploiement. Histoire raisonnable, mauvais coupable.

La correction fut ennuyeuse : ordre de montage, vérifications idempotentes (modifier un répertoire uniquement s’il est sur le filesystem attendu), et une étape
de vérification comparant la sortie de stat avec l’UID/GID attendus. Ils ont aussi arrêté de créer des répertoires quand le montage manquait.
« Supposer » est devenu un verbe banni dans les revues de code pendant un temps.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait accélérer les connexions sur postes partagés. Quelqu’un a remarqué que les ~/.cache des utilisateurs étaient volumineux et
que les supprimer semblait accélérer certains démarrages d’application. Ils ont donc mis en place une tâche hebdomadaire : vider les caches pour tous les utilisateurs.
La tâche s’exécutait en root, bien sûr.

Pendant quelques semaines, tout allait bien. Puis des tickets sont arrivés : « Mon bureau oublie mes paramètres », « Keyring me demande le mot de passe à chaque connexion »,
« Les profils navigateur se « réparent » sans cesse », « Les icônes du bureau sont réarrangées ». Quelques sessions échouaient même à démarrer.

La cause racine n’était pas le nettoyage de cache en soi. C’était la manière de l’exécuter. Le job supprimait puis recréait certains répertoires,
les laissant possédés par root. À la connexion suivante, l’environnement de bureau a tenté d’écrire dans ~/.cache et a échoué.
Certaines applis ont considéré cela comme fatal. D’autres sont reparties sur des valeurs étranges.

Le rollback fut immédiat : arrêter la tâche, restaurer l’ownership correct, et si le nettoyage de cache était nécessaire, le faire par utilisateur à la connexion
avec le bon UID, ou utiliser des politiques tmpfiles.d qui ne piétinent pas les ownerships. L’optimisation a gagné des millisecondes et perdu des jours de productivité.

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

Une équipe gérait un petit environnement VDI pour des contractuels. Les répertoires home étaient sur un array de stockage partagé. Les gens se connectaient,
modifiaient des documents, et partaient. Charge prévisible, jusqu’au jour où ce ne l’était plus.

Un matin, un sous‑ensemble d’utilisateurs a signalé que leurs Documents avaient disparu et que le Bureau était vide. La panique a vite monté
car « Documents manquants » implique souvent l’intervention des cadres. L’ingénieur de garde n’a pas lancé immédiatement des restaurations.
Il a suivi une checklist : confirmer les montages, vérifier les XDG dirs, valider les permissions, et comparer avec un utilisateur connu‑bon.

Il s’est avéré que le stockage allait bien. Les home étaient montés. Les données existaient. Le problème était un changement de template
qui avait déployé un ~/.config/user-dirs.dirs cassé à un sous‑ensemble d’utilisateurs. Desktop et Documents pointaient vers
des chemins mal orthographiés. Les données n’étaient pas parties ; ce sont les pointeurs qui l’étaient.

La pratique ennuyeuse — garder un diagnostic standard de « santé de connexion » et toujours vérifier les chemins de fichiers réels — a évité une restauration inutile,
évité du churn sur l’array de stockage, et maintenu l’incident petit. Une correction d’une ligne (xdg-user-dirs-update) a battu une restauration de plusieurs heures qui aurait créé toute une nouvelle classe de pannes.

Faits intéressants et contexte historique

Fait 1 : Le concept de « répertoire home » des utilisateurs remonte aux débuts d’Unix, où l’état spécifique à l’utilisateur vivait sous /usr avant que /home ne devienne courant.
Fait 2 : Les dotfiles sont devenus une convention parce que les fichiers cachés étaient un moyen simple de garder la configuration hors des listings de répertoire courants.
Fait 3 : Le dconf de GNOME a remplacé l’ancien GConf pour améliorer les performances et centraliser l’accès aux paramètres.
Fait 4 : Les spécifications XDG des répertoires de base ont été introduites pour réduire le chaos des applications qui dispersent config/état/cache à travers le home.
Fait 5 : L’épuisement d’inodes est un vieux problème devenu plus fréquent avec la montée des caches de paquets, node_modules, et des profils de navigateurs contenant des milliers de petits fichiers.
Fait 6 : Les problèmes de « boucle de connexion » impliquent souvent PAM et la création de session, pas la vérification du mot de passe — l’authentification réussit, la création de session échoue.
Fait 7 : Les contextes SELinux comptent parce que la politique de sécurité peut refuser l’accès même quand les permissions Unix semblent correctes.
Fait 8 : Les répertoires home réseau sont devenus populaires en entreprise parce que les sauvegardes centralisées et les profils itinérants simplifiaient la gestion du parc, au prix de latence et de risques de disponibilité.
Fait 9 : Le répertoire /etc/skel existe précisément pour semer les nouveaux home avec des dotfiles de base — utilisez‑le comme votre point de départ « connu‑bon ».

Erreurs courantes : symptôme → cause racine → correction

Voici les échecs que je rencontre souvent parce qu’ils sont faciles à déclencher et difficiles à reconnaître.

Boucle de connexion (mot de passe accepté, retour à l’écran de connexion)

Symptôme : les identifiants sont acceptés, l’écran clignote, vous revenez à GDM/SDDM.
Cause racine : home non inscriptible (permissions, quota, remontage lecture seule), ou session de bureau qui plante au démarrage à cause de la config.
Correction : Vérifiez journalctl pour « Permission denied » et « Disk quota exceeded ». Corrigez l’inscriptibilité d’abord ; puis réinitialisez dconf ou mettez en quarantaine les répertoires de config du bureau.

Le dossier Bureau apparaît vide alors que les fichiers existent dans le home

Symptôme : le Bureau n’affiche rien ; le terminal montre des fichiers sous ~/Desktop ou ailleurs.
Cause racine : mauvais mapping XDG dans ~/.config/user-dirs.dirs ou incompatibilité de répertoire localisé.
Correction : Lancez xdg-user-dirs-update, vérifiez les chemins, et assurez‑vous que les répertoires existent et ont le bon ownership.

Les applications refusent de démarrer ; erreurs liées au cache/config

Symptôme : navigateurs/apps electron plantent ; erreurs concernant ~/.cache ou ~/.config.
Cause racine : répertoires possédés par root à cause de scripts de nettoyage maladroits ou de restaurations.
Correction : chown des répertoires affectés vers l’utilisateur ; vérifiez avec un test d’écriture en tant qu’utilisateur.

Le terminal fonctionne, mais le shell interactif est cassé

Symptôme : commandes non interactives fonctionnent ; sessions interactives renvoient des erreurs.
Cause racine : .bashrc, .profile cassés, ou un script de gestionnaire de plugins qui suppose l’existence de binaires.
Correction : Démarrez avec bash --noprofile --norc. Mettez les dotfiles en quarantaine et restaurez depuis /etc/skel.

Tout semble correct, mais l’accès est refusé sur des systèmes SELinux

Symptôme : les permissions semblent correctes ; pourtant « Permission denied ». Les logs d’audit montrent des refus.
Cause racine : mauvais contexte SELinux sur le répertoire home après une restauration ou une copie manuelle.
Correction : restorecon -Rv /home/username et retentez.

La « corruption de profil » revient après que vous l’ayez réparée

Symptôme : le même utilisateur casse à nouveau quelques semaines plus tard.
Cause racine : erreurs système de fichiers sous-jacentes, disque défaillant, ou un job d’automatisation récurrent qui bafoue l’ownership.
Correction : Passez en revue dmesg, SMART, résultats de fsck, et l’automatisation du parc. Réparez le système qui brise le profil.

Checklists / plans pas à pas

Checklist A : Récupération à risque minimal (conserver le même nom d’utilisateur)

Connectez‑vous via TTY ou SSH en admin/root (évitez la session GUI cassée pour l’instant).
Vérifiez l’espace disque et les inodes sur / et /home.
Vérifiez les remontages en lecture seule et les erreurs I/O.
Sauvegardez ~/Desktop et ~/Documents (rsync avec métadonnées).
Vérifiez l’ownership et les permissions du répertoire home (ls -ld et test d’écriture en tant qu’utilisateur).
Mettez en quarantaine uniquement les coupables probables :
- ~/.config/dconf/user (GNOME)
- dotfiles shell (.bashrc, .profile)
- caches du bureau (~/.cache) si nécessaire
Corrigez le mapping XDG si Desktop/Documents sont « manquants ».
Retentez la connexion. Si cela fonctionne, réintroduisez les configs en quarantaine une par une.

Checklist B : Reconstruction propre (nouvel utilisateur, migrer les données)

Créez un nouvel utilisateur avec un home propre.
Copiez uniquement les répertoires de données (Desktop/Documents/Pictures/etc.).
Validez ownership, connexion et comportement des applications.
Copiez uniquement la config spécifique nécessaire :
- ~/.ssh (attention aux permissions)
- répertoires applicatifs spécifiques sous ~/.config (pas tout)
- sélectivement : profils navigateur, données de gestionnaire de mots de passe (seulement si vous savez ce que vous faites)
Conservez le home original comme archive jusqu’à ce que la confiance soit élevée.

Checklist C : Remédiation axée stockage (quand le système est en cause)

Si le filesystem est en lecture seule : arrêtez les travaux de récupération utilisateur ; planifiez une maintenance.
Exécutez des vérifications SMART et revoyez les logs noyau pour les erreurs I/O.
Exécutez fsck (ext4) ou l’outil de réparation approprié (XFS demande une gestion différente).
Ce n’est qu’après que le stockage est stable : procédez à la réparation/migration du profil.

FAQ

1) Qu’est‑ce qui compte comme « Desktop et Documents » sur Linux ?

Typiquement ~/Desktop et ~/Documents, mais les environnements de bureau peuvent suivre les mappings XDG depuis
~/.config/user-dirs.dirs. Vérifiez toujours ce fichier avant de déplacer quoi que ce soit.

2) Si je supprime `~/.config`, vais‑je perdre mes fichiers ?

Vous ne perdrez pas directement vos Documents, mais vous pouvez perdre les paramètres d’application, les sessions enregistrées, et parfois des données applicatives stockées sous
~/.config ou ~/.local/share. Ne supprimez pas en bloc. Mettez en quarantaine et restaurez sélectivement.

3) Pourquoi un système racine plein casse la connexion utilisateur ?

Parce que les services système doivent écrire de l’état, des logs et des fichiers runtime. Même si le home de l’utilisateur a de l’espace, un /
plein peut empêcher la configuration de session, l’activation D-Bus, ou les helpers d’identifiants de fonctionner.

4) Comment savoir si ce n’est pas un problème de pilote graphique ?

Créez un nouvel utilisateur et essayez de vous connecter. Si le nouvel utilisateur fonctionne, votre pile graphique est probablement correcte. Si personne ne peut se connecter,
c’est systémique (graphique, gestionnaire d’affichage, ou stockage).

5) Puis‑je corriger cela en réinitialisant les permissions avec `chmod -R` ?

Vous pouvez aussi résoudre un moteur bruyant en montant la radio. Ne le faites pas. Les réinitialisations de permissions sans compréhension de l’ownership, des ACLs et de SELinux
sont la manière de créer des problèmes de sécurité et de toujours échouer à démarrer une session.

6) Quelle est la manière la plus sûre de « réinitialiser » un profil ?

Créez un nouvel utilisateur et copiez d’abord uniquement les répertoires de données. C’est réversible, testable, et cela évite de courir après des fantômes de config.

7) Mes fichiers sont là, mais je ne peux pas les ouvrir. Que faire ?

Vérifiez l’ownership et les permissions des fichiers et des répertoires parents, et confirmez que l’UID correspond à celui attendu par le compte utilisateur.
Si les fichiers appartiennent à un ancien UID (après restauration), faites un chown en vous basant sur le mappage numérique d’UID.

8) Comment gérer un profil de navigateur corrompu sans perdre les favoris ?

Sauvegardez d’abord le répertoire de profil du navigateur. Ensuite exportez les favoris si le navigateur peut démarrer. Sinon, migrez uniquement les fichiers de la base de favoris
vers un profil neuf (cela dépend du navigateur). Évitez de copier l’ensemble du profil cassé comme « solution ».

9) Pourquoi l’ownership de `~/.cache` importe‑t‑elle tant ?

Parce que les bureaux modernes et les applis traitent les répertoires de cache comme un espace de travail inscriptible. S’ils ne peuvent pas y écrire, ils échouent de façon imprévisible :
plantages, état d’interface manquant, et boucles de démarrage.

10) Quand dois‑je arrêter et restaurer depuis une sauvegarde ?

Si vous voyez des erreurs I/O pendant les lectures, des messages de corruption du système de fichiers, ou des échecs répétés de copie des données utilisateur, arrêtez le dépannage du profil.
Stabilisez le stockage et restaurez depuis une sauvegarde ou un snapshot connu‑bon.

Conclusion : étapes suivantes pour rester à l’écart des ennuis

Réparer un profil utilisateur corrompu consiste surtout à résister à l’envie de gesticuler. Commencez par les fondations : espace disque, inodes, remontages en lecture seule,
ownership et quotas. Sauvegardez Desktop et Documents avant de « nettoyer » quoi que ce soit. Ensuite mettez en quarantaine les fichiers de configuration comme un professionnel, pas comme un joueur.

Étapes pratiques suivantes :

Exécutez la méthode de diagnostic rapide et notez ce que vous observez (espace, permissions, lecture seule, logs).
Faites une copie vérifiée de Desktop et Documents avec rsync.
Corrigez d’abord les problèmes d’inscriptibilité (ownership, quotas, contextes SELinux).
Si la config est en cause, réinitialisez dconf (GNOME) ou mettez en quarantaine les fichiers KDE spécifiques — un changement à la fois.
Si vous perdez toujours du temps, faites la reconstruction propre : nouvel utilisateur, migration des données, et réintroduction délibérée de la config.