Corriger “is not in the sudoers file” sous Linux

Vous lancez une commande avec sudo, et Linux vous répond froidement :

matt is not in the sudoers file. This incident will be reported.

Le message peut faire peur, surtout avec son petit ton de dénonciation administrative. En réalité, il signifie simplement que votre utilisateur n’a pas le droit d’utiliser sudo.

Sur Debian, Ubuntu et beaucoup de distributions Linux, sudo permet à un utilisateur autorisé d’exécuter une commande avec les privilèges de root. Si votre compte n’est pas dans le bon groupe ou dans la configuration sudoers, l’accès est refusé.

Voici comment corriger proprement l’erreur is not in the sudoers file, sans casser /etc/sudoers ni vous verrouiller hors du serveur.

Ce que signifie “is not in the sudoers file”

L’erreur complète ressemble généralement à ceci :

username is not in the sudoers file. This incident will be reported.

Elle indique que l’utilisateur username n’est pas autorisé à utiliser sudo. Le compte existe, le mot de passe peut être correct, mais la politique sudoers ne lui donne pas le droit d’élever ses privilèges.

En pratique, cela arrive souvent après :

• la création d’un nouvel utilisateur ;
• une installation minimale de Debian ;
• une mauvaise configuration du groupe sudo ;
• une migration de serveur ;
• une modification ratée de /etc/sudoers ;
• un compte administrateur supprimé du groupe sudo ;
• une confusion entre le compte root et un utilisateur normal.

Le “This incident will be reported” signifie que l’échec peut être journalisé dans les logs système. Ce n’est pas une plainte envoyée à Interpol. Vous pouvez donc reposer le café.

La solution recommandée : ajouter l’utilisateur au groupe sudo

Sur Debian et Ubuntu, la méthode la plus simple consiste à ajouter l’utilisateur au groupe sudo. Les membres de ce groupe peuvent généralement exécuter des commandes avec sudo.

Connectez-vous d’abord en root :

su -

Ajoutez ensuite votre utilisateur au groupe sudo :

adduser matt sudo

Remplacez évidemment matt par le nom réel de l’utilisateur.

Vous pouvez aussi utiliser usermod :

usermod -aG sudo matt

L’option -aG est importante. Elle ajoute l’utilisateur au groupe sans supprimer ses autres groupes. Oublier -a peut remplacer la liste de groupes existante. C’est rarement le moment idéal pour inventer une nouvelle panne.

Se reconnecter pour appliquer le nouveau groupe

Après l’ajout au groupe sudo, la session existante ne voit pas toujours les nouveaux groupes. Déconnectez-vous complètement, puis reconnectez-vous.

Sur un serveur SSH :

exitCode language: PHP (php)

Puis reconnectez-vous :

ssh matt@serveur.example.comCode language: CSS (css)

Vérifiez vos groupes :

groups

La sortie doit contenir sudo :

matt : matt sudo

Vous pouvez ensuite tester :

sudo whoami

Si tout fonctionne, la commande doit répondre :

root

Vérifier les droits sudo de l’utilisateur

Une fois reconnecté, vous pouvez afficher les droits sudo disponibles avec :

sudo -l

Si votre utilisateur est correctement autorisé, vous verrez une règle indiquant qu’il peut exécuter des commandes via sudo.

Sur Debian/Ubuntu, la règle classique ressemble à ceci dans /etc/sudoers :

%sudo   ALL=(ALL:ALL) ALL

Elle signifie que tous les membres du groupe sudo peuvent exécuter des commandes en tant que n’importe quel utilisateur et groupe, après authentification.

Si la commande sudo n’est pas installée

Sur certaines installations minimales de Debian, sudo peut ne pas être installé. Vérifiez :

command -v sudo

Si la commande ne retourne rien, connectez-vous en root :

su -

Puis installez sudo :

apt update
apt install sudo

Ajoutez ensuite votre utilisateur au groupe sudo :

adduser matt sudo

Reconnectez-vous, puis testez :

sudo whoami

Ajouter une règle sudo avec visudo

Dans certains cas, vous pouvez préférer ajouter une règle spécifique. Par exemple, pour donner des droits à un utilisateur précis sans l’ajouter au groupe sudo.

Ne modifiez jamais /etc/sudoers avec nano, vim ou un éditeur direct. Utilisez visudo, qui vérifie la syntaxe avant d’enregistrer.

su -
visudo

Repérez la section :

# User privilege specification
root    ALL=(ALL:ALL) ALLCode language: PHP (php)

Ajoutez une ligne pour votre utilisateur :

matt    ALL=(ALL:ALL) ALL

Enregistrez, quittez, puis testez depuis le compte utilisateur :

sudo -l
sudo whoami

Cette méthode fonctionne, mais je préfère généralement l’ajout au groupe sudo pour un administrateur classique. C’est plus lisible, plus standard, et plus facile à maintenir.

Méthode propre : créer un fichier dans /etc/sudoers.d/

Pour une règle personnalisée, la méthode la plus propre consiste souvent à créer un fichier dédié dans /etc/sudoers.d/. Cela évite de modifier directement le fichier principal /etc/sudoers.

Connectez-vous en root, puis créez un fichier avec visudo :

su -
visudo -f /etc/sudoers.d/matt

Ajoutez la règle :

matt    ALL=(ALL:ALL) ALL

Enregistrez. Ensuite, vérifiez les permissions du fichier :

chmod 0440 /etc/sudoers.d/matt

Testez la configuration globale :

visudo -c

Si la syntaxe est correcte, reconnectez-vous avec l’utilisateur et testez :

sudo whoami

Cette approche est idéale pour des règles spécifiques, par exemple un utilisateur de maintenance, un compte de déploiement, ou un administrateur temporaire.

Donner accès à toutes les commandes ou seulement à certaines ?

La règle suivante donne tous les droits :

matt    ALL=(ALL:ALL) ALL

C’est adapté pour un administrateur complet de la machine. Mais pour un compte technique ou un prestataire, vous pouvez limiter les commandes autorisées.

Exemple : autoriser uniquement le redémarrage de Nginx :

deploy  ALL=(root) /usr/bin/systemctl reload nginx, /usr/bin/systemctl restart nginx

Exemple : autoriser uniquement certaines commandes WordPress via WP-CLI serait plus délicat, car wp peut exécuter du code PHP arbitraire selon le contexte. Ne donnez donc pas un faux sentiment de limitation avec une commande trop puissante.

Pour un vrai compte d’administration, utilisez le groupe sudo. Pour un compte automatisé, créez une règle précise et documentée.

Éviter NOPASSWD sauf besoin précis

Vous trouverez souvent des exemples avec NOPASSWD :

matt    ALL=(ALL:ALL) NOPASSWD: ALL

Cette règle permet d’exécuter toutes les commandes avec sudo sans demander de mot de passe. C’est pratique. C’est aussi très large.

Je déconseille NOPASSWD: ALL pour un compte humain. Si vous en avez besoin pour une automatisation, limitez les commandes :

deploy  ALL=(root) NOPASSWD: /usr/bin/systemctl reload php8.3-fpmCode language: JavaScript (javascript)

Une règle sans mot de passe doit être courte, justifiée et compréhensible six mois plus tard. Sinon, elle deviendra cette ligne mystérieuse que personne n’ose supprimer.

Cas Ubuntu : pourquoi root n’a pas de mot de passe ?

Sur Ubuntu, le compte root n’est généralement pas utilisé directement. L’administration passe par sudo, avec le mot de passe de l’utilisateur autorisé.

Donc, si vous voyez l’erreur is not in the sudoers file sur Ubuntu, cela signifie souvent que votre utilisateur n’est plus dans le groupe sudo, ou que vous utilisez un compte non administrateur.

Si vous avez encore accès à un autre compte administrateur, utilisez-le pour corriger :

sudo usermod -aG sudo matt

Reconnectez-vous ensuite avec matt.

Cas Debian : utiliser su si sudo ne fonctionne pas

Sur Debian, il est fréquent que root ait un mot de passe défini, surtout sur une installation serveur. Si sudo ne fonctionne pas pour votre utilisateur, passez en root avec :

su -

Puis ajoutez l’utilisateur au groupe sudo :

adduser matt sudo

Si sudo n’est pas installé :

apt update
apt install sudo
adduser matt sudo

Déconnectez-vous de root, reconnectez-vous avec votre utilisateur, puis testez :

sudo whoami

Si vous n’avez plus aucun compte sudo

Si aucun utilisateur ne peut utiliser sudo et que vous ne connaissez pas le mot de passe root, il faut passer par un mode de récupération.

Sur une machine locale ou une VM, vous pouvez généralement :

• démarrer en mode recovery ;
• ouvrir un shell root ;
• remonter la racine en lecture-écriture ;
• ajouter l’utilisateur au groupe sudo ;
• redémarrer.

Exemple classique depuis un shell root recovery :

mount -o remount,rw /
adduser matt sudo
reboot

Sur un serveur dédié ou VPS, utilisez la console de secours fournie par l’hébergeur. Montez ensuite le système installé, puis corrigez les groupes ou le fichier sudoers.

Ne modifiez pas /etc/sudoers au hasard depuis un rescue mode. Une ligne mal écrite peut prolonger la panne. Linux ne manque jamais une occasion de vous rappeler qu’il sait lire la syntaxe mieux que vous.

Réparer un fichier sudoers cassé

Si sudo ne fonctionne plus après une modification de /etc/sudoers, vous avez peut-être une erreur de syntaxe.

Si vous avez encore un shell root ouvert, ne le fermez pas. Corrigez immédiatement avec :

visudo

Vous pouvez vérifier la configuration sans modifier :

visudo -c

Si le problème vient d’un fichier dans /etc/sudoers.d/, vérifiez aussi :

ls -l /etc/sudoers.d/
visudo -c

Les fichiers dans /etc/sudoers.d/ doivent généralement être lisibles en mode 0440 :

chmod 0440 /etc/sudoers.d/nom-du-fichier

Si vous n’avez plus de shell root, utilisez le mode recovery ou rescue de votre machine pour corriger le fichier.

Vérifier que le groupe sudo est bien autorisé

Ajouter l’utilisateur au groupe sudo ne suffit que si le groupe sudo est autorisé dans la configuration sudoers.

Ouvrez la configuration avec :

visudo

Vérifiez que cette ligne existe et n’est pas commentée :

%sudo   ALL=(ALL:ALL) ALL

Si la ligne commence par #, elle est commentée et ne s’applique pas :

# %sudo   ALL=(ALL:ALL) ALLCode language: PHP (php)

Retirez le # seulement si vous voulez vraiment autoriser les membres du groupe sudo à utiliser sudo.

Différence entre sudo, su et root

Les trois notions sont proches, mais elles ne veulent pas dire la même chose.

Commande ou compte	Rôle
root	Compte administrateur complet du système.
su -	Ouvre une session shell en tant que root, avec le mot de passe root.
sudo	Exécute une commande avec privilèges élevés, si l’utilisateur est autorisé.
sudo -i	Ouvre un shell root via sudo, avec les droits de l’utilisateur autorisé.

Sur Ubuntu, on utilise généralement sudo. Sur Debian, su - reste fréquent si le compte root est activé. Sur un serveur bien administré, les deux approches doivent rester maîtrisées, pas improvisées au gré des tutos.

Faut-il activer le compte root ?

Pas forcément. Sur Ubuntu, il est normal que le compte root n’ait pas de mot de passe utilisable directement. L’administration passe par sudo.

Si vous voulez vraiment définir un mot de passe pour root, vous pouvez le faire avec :

sudo passwd root

Mais ce n’est généralement pas nécessaire. Pour un poste ou serveur classique, il vaut mieux garder un compte utilisateur administrateur avec sudo, et documenter les accès proprement.

Pour verrouiller à nouveau le mot de passe root :

sudo passwd -l root

Ne confondez pas “avoir un plan de secours” et “laisser root ouvert partout”. Le premier est professionnel. Le second finit souvent dans les logs.

Commandes utiles de diagnostic

Voici les commandes utiles pour comprendre rapidement la situation :

# Qui suis-je ?
whoami

# Quels sont mes groupes ?
groups

# Groupes d’un autre utilisateur.
groups matt

# Identité complète de l’utilisateur.
id matt

# sudo est-il installé ?
command -v sudo

# Droits sudo de l’utilisateur courant.
sudo -l

# Vérifier le fichier sudoers.
visudo -c

# Voir les fichiers de règles locales.
ls -l /etc/sudoers.d/

# Vérifier la règle du groupe sudo.
grep -E '^%sudo' /etc/sudoers

# Ajouter un utilisateur au groupe sudo depuis root.
adduser matt sudo

# Alternative avec usermod.
usermod -aG sudo mattCode language: PHP (php)

Exemple de correction complète sur Debian

Voici une correction simple sur Debian quand vous connaissez le mot de passe root.

su -
apt update
apt install sudo
adduser matt sudo
visudo -c
exitCode language: PHP (php)

Déconnectez-vous complètement, reconnectez-vous avec matt, puis testez :

groups
sudo whoami
sudo -l

Si sudo whoami répond root, la correction est bonne.

Exemple de correction complète sur Ubuntu

Sur Ubuntu, si vous disposez encore d’un autre compte administrateur :

sudo usermod -aG sudo matt

Déconnectez ensuite l’utilisateur matt, reconnectez-le, puis testez :

groups
sudo whoami

Si aucun compte administrateur ne fonctionne, utilisez le mode recovery pour ajouter l’utilisateur au groupe sudo.

Erreurs fréquentes

J’ai ajouté l’utilisateur au groupe sudo, mais l’erreur continue

Déconnectez-vous complètement, puis reconnectez-vous. Les groupes sont appliqués à l’ouverture de session. Une session déjà ouverte ne récupère pas toujours les nouveaux droits.

Le groupe sudo n’existe pas

Installez d’abord le paquet sudo si nécessaire. Sur certaines distributions, le groupe peut être différent, par exemple wheel sur plusieurs systèmes de la famille Red Hat.

Sur Debian/Ubuntu, le groupe attendu est généralement sudo.

visudo ouvre vim et je ne sais pas quitter

Classique. Pour utiliser nano avec visudo, lancez :

EDITOR=nano visudo

Ou pour un fichier dédié :

EDITOR=nano visudo -f /etc/sudoers.d/matt

sudo demande encore un mot de passe

C’est normal. Par défaut, sudo demande le mot de passe de l’utilisateur courant. Cela ne signifie pas que la configuration est mauvaise.

Je veux utiliser sudo sans mot de passe

Utilisez NOPASSWD seulement pour un besoin précis, idéalement sur une commande limitée. Évitez NOPASSWD: ALL pour un compte humain.

Ce qu’il ne faut pas faire

• Modifier /etc/sudoers directement avec nano ou vim.
• Fermer votre seul shell root avant d’avoir testé sudo.
• Utiliser NOPASSWD: ALL sans raison sérieuse.
• Ajouter tous les utilisateurs au groupe sudo.
• Créer un compte administrateur partagé entre plusieurs personnes.
• Utiliser usermod -G sudo user sans -a.
• Commenter ou supprimer la règle %sudo sans comprendre l’impact.
• Donner des droits root à une application qui n’en a pas besoin.

sudo est un outil de délégation de privilèges. Il doit rester prévisible, documenté et limité aux comptes qui en ont réellement besoin.

Besoin d’aide pour réparer un serveur Linux ?

Checklist de correction

• Vérifier le nom de l’utilisateur avec whoami.
• Vérifier ses groupes avec groups ou id.
• Se connecter en root avec su - si sudo ne fonctionne pas.
• Installer sudo si le paquet est absent.
• Ajouter l’utilisateur au groupe sudo avec adduser user sudo.
• Vérifier que la règle %sudo ALL=(ALL:ALL) ALL existe.
• Utiliser visudo pour toute modification.
• Préférer /etc/sudoers.d/ pour les règles personnalisées.
• Déconnecter puis reconnecter l’utilisateur.
• Tester avec sudo whoami.
• Vérifier avec sudo -l.
• Éviter NOPASSWD: ALL sauf besoin très clair.
• Garder un accès root ou console tant que la correction n’est pas validée.

FAQ : erreur “is not in the sudoers file”

Pourquoi Linux affiche “is not in the sudoers file” ?

Parce que votre utilisateur n’est pas autorisé à utiliser sudo. Il n’est pas membre d’un groupe autorisé, comme sudo, et aucune règle sudoers ne lui donne ce droit.

Comment corriger rapidement cette erreur sur Debian ou Ubuntu ?

Connectez-vous en root ou avec un autre administrateur, puis ajoutez l’utilisateur au groupe sudo avec adduser username sudo. Déconnectez-vous ensuite complètement, puis reconnectez-vous.

Pourquoi faut-il utiliser visudo ?

visudo verrouille le fichier sudoers et vérifie sa syntaxe avant enregistrement. Une erreur dans sudoers peut empêcher sudo de fonctionner.

Faut-il modifier /etc/sudoers ou utiliser /etc/sudoers.d/ ?

Pour un utilisateur administrateur classique, ajoutez-le au groupe sudo. Pour une règle personnalisée, créez plutôt un fichier dédié dans /etc/sudoers.d/ avec visudo -f.

Pourquoi sudo ne fonctionne toujours pas après ajout au groupe sudo ?

Votre session n’a probablement pas encore récupéré les nouveaux groupes. Déconnectez-vous complètement, reconnectez-vous, puis vérifiez avec groups.

Puis-je donner sudo sans mot de passe ?

Oui avec NOPASSWD, mais je le déconseille pour un compte humain avec tous les droits. Si nécessaire, limitez cette option à quelques commandes précises.

Sources

• Debian Wiki : sudo
• Linux man-pages : sudoers(5)
• Debian manpages : sudoers(5)
• Ubuntu Server documentation : user management and sudo
• Debian Wiki : system groups
• SkyMinds : corriger “only root can unmount” sous Linux
• SkyMinds : désactiver les emails de notification d’une tâche cron
• SkyMinds : réinitialiser le mot de passe root MySQL/MariaDB sous Debian

Report a typo