"user is not in the sudoers file": how to get sudo back, even without the root password

1. Add yourself to the admin group

sudo allows one group by default, and which one depends on the distribution:

Become root with su -. It asks for root’s password, not yours, and that’s the difference from sudo. Then add the user:

usermod -aG sudo alex

Keep the -a. Without it, -G replaces all of the user’s other groups rather than adding to them.

The Debian installer has a catch: if you set a root password during setup, it doesn’t put your first user in sudo, and that’s the usual way people first see this message. It may not even have sudo installed: apt install sudo as root.

2. Log out, then check

The groups of a session are fixed when it starts, so the running shell doesn’t know yet:

exit            # or log out of the desktop

Log in again and check:

groups
sudo -l

User alex may run the following commands on server01:
    (ALL : ALL) ALL

3. Without the root password

On Ubuntu, root has no password by default, so su - fails with Authentication failure. Your first user normally has sudo. If you’ve lost it, you need a way in from outside the running system.

A cloud server. Use the provider’s tools, as they can act as root: AWS Systems Manager Session Manager, the Azure Run Command or serial console, or Google Cloud’s serial console or gcloud compute ssh, which manages sudo access itself. As a last resort, detach the disk, attach it to another machine and edit the files from there.

A machine with a console. Boot into recovery from GRUB:

1. Restart, and hold Shift (BIOS) or press Esc (UEFI) to see the GRUB menu.
2. Highlight the normal entry, and press e.
3. On the line starting with linux, add init=/bin/bash at the end. Press F10 or Ctrl+X.
4. You get a root shell with no password:

mount -o remount,rw /
usermod -aG sudo alex
sync
exec /sbin/init

Instead of init=/bin/bash, Ubuntu also has Advanced options → recovery mode → root. Encrypted disks still ask for their passphrase, and some setups protect GRUB with a password. RHEL with SELinux needs one more step before rebooting, or files can be labelled wrongly: touch /.autorelabel.

4. Giving exact rights with sudoers

The group gives everything. For a specific user or limited rights, add a file in /etc/sudoers.d/, and always edit it through visudo, as it checks the syntax before saving:

sudo visudo -f /etc/sudoers.d/alex

alex ALL=(ALL:ALL) ALL

That’s everything again, as user alex. Limited to restarting one service, it would be:

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

Use full paths, and take care with commands like vim, less or tar: they can run a shell, so granting them means granting everything. File names in that folder can’t contain a . or end in ~, or sudo silently ignores them. Permissions must be 0440:

sudo chmod 440 /etc/sudoers.d/alex

5. You broke the sudoers file

Editing /etc/sudoers directly can lock everyone out:

>>> /etc/sudoers: syntax error near line 28 <<<
sudo: parse error in /etc/sudoers near line 28
sudo: no valid sudoers sources found, quitting

If you have the root password, su -, then visudo to fix it. On a machine using polkit, this often works without root’s password, for a user in the admin group:

pkexec visudo

Otherwise, use the recovery in section 3. If the error names a file in /etc/sudoers.d/, you can simply remove that file. To check everything at the end:

sudo visudo -c