Impossible d'ouvrir sa session Linux : diagnostiquer et réparer la boucle de connexion.

01 — Le symptômeUne session qui reboucle ou se referme, un mot de passe pourtant accepté

Le scénario type : vous tapez votre mot de passe sur l'écran de connexion (LightDM, GDM, SDDM…), l'écran devient noir une seconde, puis l'écran de connexion revient. Pas de message d'erreur, pas de refus du mot de passe — s'il était faux, le système vous le dirait. Variante : la session s'ouvre, le bureau apparaît partiellement, puis tout se referme au bout de quelques secondes.

Le même problème prend d'autres visages selon la façon d'accéder à la machine :

• en bureau à distance (xrdp, VNC), la connexion est acceptée puis coupée aussitôt, ce qui fait croire à un problème réseau ;
• les applications déjà ouvertes continuent parfois de fonctionner un moment, puis se dégradent une à une (icônes manquantes, paramètres perdus, services utilisateur en erreur) ;
• la connexion SSH, elle, peut rester possible, ce qui est précieux pour réparer.

Ce contraste — mot de passe accepté mais session impossible — est la signature du problème : l'authentification réussit, c'est l'ouverture de l'environnement de travail qui échoue. Et pour s'ouvrir, un environnement de bureau doit lire et écrire des dizaines de fichiers dans votre répertoire personnel : .profile, .config/, .cache/, fichiers de session… Si l'accès à ce répertoire est bloqué, tout s'arrête là.

02 — La causeLe bit d'exécution du répertoire personnel, clef de voûte de la session

Sous Linux, les droits d'un répertoire ne fonctionnent pas comme ceux d'un fichier. Le droit de lecture (r) permet de lister le contenu, mais c'est le droit d'exécution (x) qui permet de traverser le répertoire, c'est-à-dire d'accéder à ce qu'il contient. La page de manuel path_resolution(7) est explicite : pour atteindre /home/utilisateur/.config/monfichier, le système doit avoir le droit de traverser /home, puis /home/utilisateur, puis .config. Qu'un seul maillon perde son bit x, et plus rien derrière n'est accessible — quels que soient les droits des fichiers eux-mêmes.

Un répertoire personnel sain affiche drwxr-xr-x (755) ou drwxr-x--- (750). Un répertoire en drw------- (600) semble presque normal à l'œil — il manque juste une lettre — mais il est devenu infranchissable, y compris pour son propre propriétaire.

Comment en arrive-t-on là ? Presque toujours par une commande chmod qui n'a pas touché sa cible prévue :

• un copier-coller tronqué : une commande du type chmod 600 ~/dossier/long/chemin/fichier dont la ligne se coupe après le ~ — le chmod s'applique alors au répertoire personnel entier ;
• un chmod avec un joker ou une variable vide (chmod 600 $DIR/* quand $DIR ne vaut rien) ;
• un chmod -R « de sécurisation » appliqué trop haut dans l'arborescence ;
• une restauration de sauvegarde ou une copie (rsync, unzip) effectuée en root, qui recrée les dossiers avec les mauvais droits ou le mauvais propriétaire.

03 — Le diagnosticCinq minutes en console pour confirmer la cause

Premier réflexe : ne pas redémarrer en boucle, cela ne changera rien. Ouvrez une console texte avec Ctrl+Alt+F3 (ou F2 à F6 selon les distributions), et connectez-vous avec votre identifiant et votre mot de passe habituels. La console n'a pas besoin de l'environnement graphique : elle fonctionne généralement même quand la session de bureau est bloquée. Si la machine est joignable en SSH, c'est tout aussi bien.

Vérifiez ensuite les droits du répertoire personnel :

ls -ld /home/votre_nom

La réponse attendue commence par drwxr-xr-x. Si vous lisez drw-------, drw-r--r-- ou toute forme sans x dans le premier bloc, le diagnostic est posé. Profitez-en pour vérifier le propriétaire (les deux colonnes suivantes doivent afficher votre identifiant, pas root).

Les journaux systèmes confirment le tableau, avec un piège d'interprétation qu'il faut connaître. Dans la sortie de journalctl -b, vous verrez des erreurs de ce genre :

systemd[1234]: Failed to open /home/votre_nom/.config/..., ignoring: Permission denied
pam: Error ... /home/votre_nom/... : Permission denied

Le réflexe naturel est d'examiner chaque fichier cité. C'est une fausse piste : quand un répertoire parent n'est pas traversable, le système renvoie EACCES (« Permission denied ») avant même de vérifier si le fichier final existe — la page path_resolution(7) décrit précisément ce mécanisme. Des « Permission denied » en rafale sur des chemins variés, parfois sur des fichiers qui n'ont jamais existé, désignent en réalité un seul coupable : le répertoire parent.

Si les droits du répertoire sont corrects, deux autres vérifications couvrent l'essentiel des cas restants :

• le disque plein : df -h /home — à 100 %, la session ne peut plus écrire ses fichiers temporaires et reboucle de la même façon ;
• des fichiers passés sous root : ls -la /home/votre_nom | grep root — typiquement .Xauthority ou .ICEauthority, conséquence d'un lancement d'application graphique avec sudo.

04 — La réparationUne commande, puis une vérification

La réparation tient en une commande, à passer depuis la console ou en SSH. Si votre compte le permet, précédez-la de sudo ; sinon, connectez-vous en root. Écrivez le chemin en entier, sans ~ ni variable — c'est précisément ce genre de raccourci qui provoque l'incident :

chmod 755 /home/votre_nom

Préférez 750 si vous ne voulez pas que les autres comptes de la machine puissent lire vos dossiers (sur un poste personnel, 755 est le réglage par défaut de la plupart des distributions ; le chapitre « gestion des droits » du Cahier de l'administrateur Debian détaille la signification de chaque valeur). N'utilisez jamais 777 : au-delà du risque de sécurité, certains composants refusent de fonctionner avec des droits trop ouverts — SSH, par exemple, ignore un dossier .ssh accessible en écriture à d'autres comptes.

Vérifiez immédiatement le résultat :

ls -ld /home/votre_nom

Puis retournez sur l'écran de connexion (Ctrl+Alt+F1 ou Ctrl+Alt+F7 selon les systèmes) et ouvrez votre session. Dans la plupart des cas, tout revient instantanément, paramètres et fichiers intacts : rien n'a été perdu, l'accès était simplement verrouillé. Un redémarrage n'est utile que si des services de session sont restés en erreur.

Si le diagnostic avait révélé des fichiers appartenant à root, rendez-les à leur propriétaire en les ciblant explicitement :

chown votre_nom:votre_nom /home/votre_nom/.Xauthority /home/votre_nom/.ICEauthority

Évitez le chown -R global sur tout le répertoire tant que vous n'avez pas identifié ce qui a changé : sur une machine qui héberge des services ou des montages particuliers, un changement de propriétaire en masse peut créer de nouveaux problèmes.

05 — La préventionLes habitudes qui évitent de recommencer

Cet incident est bénin quand on en connaît la cause, mais il immobilise un poste de travail — et il est entièrement évitable. Quatre habitudes suffisent :

• Chemins absolus et complets pour toute commande chmod, chown ou rm : pas de ~, pas de variable non vérifiée, pas de joker sur un chemin construit. Une commande qui change des droits mérite sa propre ligne, suivie d'un ls -ld de contrôle.
• Jamais de sudo pour lancer une application graphique : c'est la source classique des fichiers de session passés sous root. Les outils modernes (pkexec, les éditeurs avec élévation intégrée) gèrent ce cas proprement.
• Relire avant d'exécuter ce qui vient d'un copier-coller — une ligne de commande collée depuis un document ou une page web peut avoir été coupée en deux au passage, et chaque moitié exécutée séparément.
• Des sauvegardes testées, parce que la prochaine erreur de manipulation ne sera peut-être pas aussi réversible que celle-ci. Nous détaillons la règle 3-2-1 dans notre article sur la sécurisation d'un site internet, et elle s'applique tout autant à un poste de travail.

Sur un parc de machines ou des serveurs qui hébergent vos outils de travail, ce type d'incident justifie une supervision : détecter une avalanche de « Permission denied » dans les journaux avant que l'utilisateur ne soit bloqué, c'est exactement le rôle d'une infogérance. Et si vous administrez vous-même vos serveurs, notre article sur l'hébergement de ses propres sites complète le sujet.

Questions fréquentes