mediumFoundationSymptom-first#sudo#sudoers#permissions#admin#access

Sudo not working — user not authorized for sudo

sudo: <user> is not in the sudoers file. This incident will be reported.

Likely source:configurationsecurity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • sudo: <user> is not in the sudoers file. This incident will be reported.
  • User cannot run privileged commands
  • Password prompt appears but authentication fails even with correct password

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • User sudo access

    sudo -l -U <user>

  • Sudoers file contents

    cat /etc/sudoers | grep <user> || cat /etc/sudoers.d/<user>

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • sudo -l returns 'not in the sudoers file'
  • grep finds no entry for the user or their group

Confirm before fixing

sudo -l -U <user>
READ

Confirm no sudo access

Fix

usermod -aG sudo <user>
CHANGE

Add the user to the sudo group (Debian/Ubuntu)

echo '<user> ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/<user>
CHANGE

Create a drop-in file for the user

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
sudo -l -U <user>
READ

Check current sudo privileges

2
grep -r '<user>' /etc/sudoers /etc/sudoers.d/ 2>/dev/null
READ

Search for the user in sudoers files

3
visudo -cf /etc/sudoers
READ

Validate sudoers syntax

4
usermod -aG sudo <user>
CHANGE

Add the user to the sudo group

Prevention

  • Use /etc/sudoers.d/ drop-in files instead of editing /etc/sudoers directly.
  • Always validate with visudo -cf before saving changes to sudoers.
  • Use Ansible/Puppet to manage sudoers entries consistently across hosts.
  • Limit NOPASSWD to specific commands instead of ALL.

Related runbooks

Same stack, same failure family — worth a skim.

Permission denied — file access denied due to ownership or modemedium

Permission denied when accessing a file or directory

LinuxFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.