Blog
3 min read

"User Is Not in the Sudoers File": What It Means and How to Fix It

"username is not in the sudoers file. This incident will be reported." means your Linux user isn't allowed to run commands as root with sudo. How to add a user to the sudo (or wheel) group from root, edit sudoers safely with visudo, recover when you've locked yourself out, and the safer alternatives to giving out sudo.

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

(or on newer systems: ana is not in the sudoers file.)

This means your user account isn't allowed to use sudo — the command that runs things with administrator (root) privileges. Linux keeps a list of who may use sudo, and you're not on it.

"This incident will be reported" sounds scary, but it just means the failed attempt was written to the system log. Nobody is coming for you.

Why it happens

  • You created a new user on a server and didn't grant admin rights.
  • You're on a shared or managed machine where you're deliberately not an admin.
  • A fresh install where only root was set up.

Fix: add the user to the sudo group

You need to run this as someone who already has admin rights — usually root.

Become root. If you know the root password:

su -

Or log in as root over SSH, or use your cloud provider's web console.

Add your user to the admin group:

# Debian, Ubuntu
usermod -aG sudo ana

# Fedora, RHEL, Rocky, Arch
usermod -aG wheel ana

-aG means "append to group" — leaving out -a would remove the user from all their other groups.

On Arch and other installations where wheel access isn't enabled by default, an administrator must also use visudo to enable %wheel ALL=(ALL:ALL) ALL. Group membership alone grants nothing unless sudoers allows that group.

Log out and back in (group changes apply to new sessions), then check:

groups
sudo whoami     # should print: root

Editing sudoers directly (carefully)

For custom rules, edit the sudoers file — only with visudo, which checks the syntax before saving. A typo saved with a normal editor can lock everyone out of sudo.

sudo visudo
# or put custom rules in their own file:
sudo visudo -f /etc/sudoers.d/deploy

Example: let a deploy user restart one service without a password, and nothing else:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

Locked yourself out?

If no account has sudo and you don't know the root password:

  • Cloud servers: use the provider's web console or rescue mode to boot a recovery system, mount the disk, and fix the group or sudoers file.
  • Your own machine: boot into recovery mode (on Ubuntu, from the GRUB menu), which gives a root shell.

Should you give out sudo at all?

Sudo is full control of the machine. Follow the principle of least privilege:

  • Give sudo only to people who administer the server.
  • Run apps as their own unprivileged user, never as root. (Writing a systemd Service File)
  • Use narrow sudoers rules (like the deploy example) for automation.
  • On a server, disable root login over SSH once your sudo user works. (SSH Hardening)

The summary

  • Your user isn't allowed to use sudo.
  • As root: usermod -aG sudo username (or wheel), then log out and in.
  • Edit sudoers only with visudo, and keep sudo access to a minimum.

EasySpawn servers are managed for you — security updates, HTTPS and backups are handled — so day-to-day app work never needs root, and Claude Code works within your project's permissions. See how it works or join the waitlist.

Related: Secure a New VPS · Linux File Permissions · Linux Capabilities · Basic Linux Commands

Keep reading