Linux  ·  critical  ·  Access, hardening & packages

sudo is broken — "syntax error in /etc/sudoers" and no way back in

A bad edit to sudoers locks out every route to root that depends on sudo — which, on most modern installs, is all of them.

What you see

Every sudo command fails with a parse error, or reports that the user may not run sudo. The root account may have no password set at all.

What is actually wrong

Editing /etc/sudoers with a plain editor rather than visudo, a file in sudoers.d with wrong permissions, or a syntax error in an included file.

Codes and articles

syntax error in /etc/sudoerssudo: parse erroris not in the sudoers filesudo: /etc/sudoers is owned by uid

Fixes (2)

Repair it from the session you still have
An open root shell15 minutesmedium riskreversible

You still have root somewhere. Do not close that session.

  1. Do not close the session. It is the only route in.

    This is worth stating first because the instinctive response — closing the terminal and opening a new one to test — is what turns a five-minute fix into a trip to the console.

  2. Check what is wrong.

    Shell
    visudo -c
  3. Fix the named file with visudo, which refuses to save a file that does not parse.

    Shell
    visudovisudo -f /etc/sudoers.d/90-custom
  4. Check the permissions, which sudo enforces strictly and which cause a refusal with no syntax error at all.

    Shell
    ls -l /etc/sudoers /etc/sudoers.d/chmod 440 /etc/sudoerschmod 440 /etc/sudoers.d/*chown root:root /etc/sudoers /etc/sudoers.d/*
  5. Note that files in sudoers.d with a dot or a tilde in the name are ignored entirely — a file saved as 90-custom.bak is silently skipped, which is often the actual cause.

  6. Test from a second terminal before closing the first.

    Shell
    sudo -l
Confirm it workedvisudo -c reports the files parse, and sudo works from a fresh session.
Shell
visudo -c && sudo -v && echo ok
If you need to undo itvisudo keeps the previous file until a valid one is saved.
Recover from the console
Physical or hypervisor console40 minuteshigh riskreversible

No root session anywhere.

  1. Reboot and interrupt the boot loader. At the GRUB menu, press e on the default entry.

  2. Add init=/bin/bash to the end of the linux line, then boot with Ctrl-X.

    Shell
    linux /vmlinuz-... root=/dev/mapper/vg0-root ro init=/bin/bash

    This starts a root shell in place of init, before any service or authentication runs. It requires console access, which is precisely why physical and console access must be treated as equivalent to root.

  3. Remount the root filesystem writable.

    Shell
    mount -o remount,rw /
  4. Fix the file, then verify before rebooting.

    Shell
    visudo -cchmod 440 /etc/sudoers
  5. Reboot cleanly.

    Shell
    exec /sbin/init
  6. On a cloud instance where the console cannot do this, attach the volume to another instance, repair the file there, and reattach.

Confirm it workedThe machine boots normally and sudo works.
Shell
sudo -v && echo ok
If you need to undo itNothing else was changed. Note that if the disk is encrypted, the passphrase is still required.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.