🚨 Linux Error: 'is not in the sudoers file. This incident will be reported.' — Cause, Fix, and Troubleshooting Guide

What this error means

You run a command with sudo and instead of a password prompt you get a curt refusal:

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

This comes from the sudo security policy plugin (sudoers). It means sudo consulted /etc/sudoers and every drop-in under /etc/sudoers.d/, found no rule matching your user, host, and command, and refused. The alarming “This incident will be reported” line is just the default sudo lecture — it writes the denied attempt to the auth journal. It is not evidence of an attack, and there is no remote “report” being filed.

The usual root cause is mundane: the account is not in the privilege group (sudo on Debian/Ubuntu, wheel on RHEL/Fedora), or a hand-edited sudoers file is broken and silently ignored.

How it manifests on the host

• sudo <cmd> prints <user> is not in the sudoers file. This incident will be reported. and exits without running the command.
• The user can log in normally over SSH but cannot escalate to root.
• sudo -l reports Sorry, user deploy may not run sudo on <host>.
• The failure started right after a host cleanup, a group change, or an edit to /etc/sudoers.
• journalctl -t sudo shows lines like deploy : user NOT in sudoers.

System configuration causes

1. Not in the privilege group. The user was never added to, or was removed from, sudo (Debian/Ubuntu) or wheel (RHEL/Fedora), so the group-based rule no longer matches.
2. A broken /etc/sudoers or drop-in. A file was edited by hand (not with visudo) and now has a syntax error. sudo refuses to load a malformed sudoers tree and falls back to “no rules,” denying everyone.
3. Missing @includedir line. Someone edited /etc/sudoers directly and dropped the @includedir /etc/sudoers.d (older: #includedir) directive, so every drop-in rule is ignored.
4. Wrong mode/owner on a drop-in. sudo silently skips any file in /etc/sudoers.d/ that is not 0440 and root:root, or whose name contains a . or ~.
5. Stale group session. The user was just added to sudo/wheel but has not started a new login session, so the current shell still lacks the group.

Interrogating the host

Run these read-only checks first — they change nothing.

1. Confirm what sudo believes the user may do:

   sudo -l -U deploy

   not allowed to run sudo means no rule matches — a group or rule problem, not a password problem.

2. Check group membership:

   id deploy
   getent group sudo wheel

   If deploy is not listed in sudo (Debian/Ubuntu) or wheel (RHEL/Fedora), the group rule cannot apply.

3. Validate the entire sudoers tree parses cleanly:

   sudo visudo -c

   Any file it flags as bad is being ignored in full.

4. Inspect the drop-ins and the include directive:

   ls -l /etc/sudoers.d/
   sudo grep -E 'includedir|@include' /etc/sudoers

   Files must be -r--r----- root root (0440), and the @includedir /etc/sudoers.d line must be present.

5. Read the denied attempts:

   sudo journalctl -t sudo --since '15 min ago'

Remediation

Important: always keep a second root shell open (or console/out-of-band access ready) while changing sudo policy, so a mistake cannot lock you out.

1. Add the user to the privilege group from any working root or sudo session:

   sudo usermod -aG sudo deploy      # Debian/Ubuntu
   sudo usermod -aG wheel deploy     # RHEL/Fedora/Rocky

   The user must log out and back in for the new group to take effect (id in a fresh shell confirms it).

2. Repair a broken sudoers file — only with visudo, never a plain editor. visudo refuses to save syntactically invalid content:

   sudo visudo                                   # edits /etc/sudoers safely
   sudo visudo -f /etc/sudoers.d/deploy          # edits a specific drop-in safely

   Restore the include line if it was lost:

   @includedir /etc/sudoers.d

3. Fix drop-in permissions so sudo will load the file:

   sudo chown root:root /etc/sudoers.d/deploy
   sudo chmod 0440 /etc/sudoers.d/deploy

4. Grant a scoped rule (preferred over blanket access) via a validated drop-in:

   echo 'deploy ALL=(ALL) /usr/bin/systemctl' | sudo visudo -cf -   # validate first
   echo 'deploy ALL=(ALL) /usr/bin/systemctl' | sudo tee /etc/sudoers.d/deploy
   sudo chmod 0440 /etc/sudoers.d/deploy

5. Recover when you are fully locked out (no working sudo/root shell):

   • Console as root. Log in directly as root on the physical/virtual console (if root login is enabled) and run the usermod/visudo fixes above.
   • Single-user / recovery mode. Reboot, select the recovery entry in GRUB, and the shell there is root — remount read-write with mount -o remount,rw / if needed, then fix the group or sudoers file.
   • pkexec (PolicyKit) can sometimes run a command as root when sudo is broken:

     pkexec usermod -aG sudo deploy

   • Cloud instances: attach the root volume to a rescue instance, or use the provider’s serial console / user-data to reset access.

Hardening the host

• The “This incident will be reported” line is the default sudo lecture, not an alert to anyone. Do not treat it as a security event.
• Group changes apply only to new login sessions — always re-login (or run newgrp sudo) before re-testing.
• A single bad drop-in disables the whole sudoers tree, not just that file. If one user loses sudo, check visudo -c before assuming it is user-specific.
• Editing /etc/sudoers with vi/nano directly is how most lockouts happen. Use visudo (or visudo -f) every time — it is the syntax gate.
• On RHEL/Fedora the group is wheel, on Debian/Ubuntu it is sudo. Adding a user to the wrong group looks correct in id but never matches the rule.

Related system errors

• Linux Error: Operation not permitted
• Security Error: user is not in the sudoers file (privilege escalation / hardening angle)
• Linux Error: Host key verification failed

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.