314

How do I edit an invalid sudoers file? It throws the below error and it's not allowing me to edit again to fix it.

Here is what happens:

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

18 Answers 18

479
+50

On a modern Ubuntu system (and many other GNU/Linux distributions), fixing a corrupted sudoers file is actually quite easy, and doesn't require rebooting, using a live CD, or physical access to the machine.

To do this via SSH, log in to the machine and run the command pkexec visudo. If you have physical access to the machine, SSH is unnecessary; just open a Terminal window and run that pkexec command.

Assuming you (or some other user) are authorized to run programs as root with PolicyKit, you can enter your password, and then it will run visudo as root, and you can fix your /etc/sudoers.

If you need to edit one of the configuration files in /etc/sudoers.d (which is uncommon in this situation, but possible), use pkexec visudo -f /etc/sudoers.d/filename.

If you have a related situation where you have to perform additional system administration commands as root to fix the problem (also uncommon in this circumstance, but common in others), you can start an interactive root shell with pkexec bash. Generally speaking, any non-graphical command you'd run with sudo can be run with pkexec instead.

(If there is more than one user account on the system authorized to run programs as root with PolicyKit, then for any of those actions, you'll be asked to select which one you want to use, before being asked for your password.)


If that doesn't work--for example, if there are no users authorized to run programs as root via PolicyKit--then boot from an Ubuntu live CD (like the CD you probably used to install Ubuntu) and mount the filesystem for the installed system. You can do this by running sudo parted -l to view your partitions--there is probably just one ext4 partition, and that's the root filesystem.

Suppose the installed Ubuntu system's root filesystem is on /dev/sda1. Then you could mount it with sudo mount /dev/sda1 /mnt. Then you can edit the installed system's sudoers file with sudo nano -w /mnt/etc/sudoers. Or, even better, you can edit it with

sudo visudo -f /mnt/etc/sudoers

(which will prevent you from saving a sudoers file with incorrect syntax).

19
  • 7
    pkexec /usr/sbin/visudo worked on debian 7
    – marinara
    Mar 5, 2014 at 1:33
  • 11
    HOLY COW! Thanks a LOT! Saved my bacon. Added a file as suggested into etc/sudoers.d/ directory USING A REGULAR TEXT EDITOR (D-O-N-T__D-O__T-H-A-T!!!). Lost all ability to do elevated privileges, INCLUDING, editing the offending file. This helped edit the file. Weird though, I had to edit /etc/sudoers first, then it found the errors in the other file and opened that for me. EVEN WEIRDER, the directive in /etc/sudoers file 'inlcudedir /etc/sudoers.d' was commented out, and it still includes it.
    – Dennis
    Apr 5, 2015 at 3:15
  • 5
    @Dennis Somewhat confusingly, #include directives in sudoers files are treated specially; the leading # does not cause the rest of the line to be interpreted as a comment, in that case. As man sudoers says: "The pound sign (‘#’) is used to indicate a comment (unless it is part of a #include directive or unless..." See also visudo: #includedir sudoers.d (archived from lzone.de/blog). Apr 5, 2015 at 3:49
  • 9
    My user is sudoer but i got this error: Error executing command as another user: Not authorized
    – SuB
    Oct 30, 2016 at 10:05
  • 10
    In Ubuntu 16.04, pkexec visudo asks for a password, which does not accept the correct password. It throws an "AUTHENTICATION FAILED" error. Aug 14, 2018 at 9:30
79

Always use visudo to edit your sudoers file, never edit it directly yourself. It will prevent you saving it to disk unless it validates.

5
  • 33
    hindsight is 20/20
    – code_monk
    Jan 9, 2015 at 1:57
  • 8
    It won't prevent disaster. It's easy enough to validly deny yourself.
    – Joshua
    Oct 5, 2015 at 22:02
  • Can visudo be used by scritps? If so, how?
    – Lukas
    Jul 7, 2016 at 15:01
  • I don't have visudo installed. So I did pkexec vim. Then it shows the list of users and asks for password. When I provide password, it throws error as " Error executing command as another user: Not authorized". Please help May 24, 2018 at 5:48
  • 1
    @Shyamkkhadka Copied from another comment: Note: if you're not running a graphical linux flavor you might get ` GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie`. Do not lose hope; see github.com/NixOS/nixpkgs/issues/18012 for a solution Jun 8, 2022 at 19:33
34

Type in:

pkexec visudo

Then change last line

#includedir /etc/sudoers

To:

#includedir /etc/sudoers.d

It should solve your problem.

3
  • 2
    I've noticed that removing the leading # from #includedir causes syntax errors, the # is part of the directive, at least on Ubuntu 12.10.
    – SAFX
    Apr 5, 2013 at 2:46
  • 1
    That just saved me a lot of headache. Thanks a ton :) Jul 16, 2017 at 18:29
  • 2
    I don't have visudo installed. So I did pkexec vim. Then it shows the list of users and asks for password. When I provide password, it throws error as " Error executing command as another user: Not authorized". Please help May 24, 2018 at 5:48
26

When this happens to a non-GUI system (your production server, maybe) the pkexec fails with this error message:

polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

In this situation, using pkttyagent can be helpful. If you want to remove a corrupted file in sudoers.d directory, use this:

pkttyagent -p $(echo $$) | pkexec rm /etc/sudoers.d/FILENAME

If you want to recover the default /etc/sudoers, you can use this gist to copy the default configurations, putting it in a non-root accessed place (e.g. your $HOME). Then, you can overwrite your sudoers file:

pkttyagent -p $(echo $$) | pkexec cp ~/sudoers /etc/sudoers

NOTE: Using this approach, after running your command, probably your access to the shell will be gone. But I'm sure losing one shell session is much better than losing your server! (According to the manpage, this is the normal behavior: When its services are no longer needed, the process can be killed.)

7
  • Thanks so much for this!
    – pat-s
    Dec 1, 2020 at 14:32
  • This is great material, thanks mate!
    – alleen1
    Aug 16, 2021 at 9:00
  • Thanks so much... just saved an embedded device from needing reflashing ;)
    – Martin
    Oct 28, 2021 at 11:34
  • lifesaver! thanks
    – Jayden
    Feb 9, 2022 at 20:26
  • I get super excited each time I get a comment here. I'm very glad to be helpful guys.
    – Ali Tou
    Feb 10, 2022 at 2:33
17

if anyone else like me didn't have pkexec installed, or was not able to run vi, visudo, nano or any other editor to change sudoers file you can be sure with this process.. I was saved with this:

  • reboot
  • hold shift key while booting to have option for recovery mode (enter it)
  • enter command line as root (second last option at my grub menu)
  • remount boot device for rw, and apply exec right for user, and edit file

    mount -n -o remount,rw /
    chmod u+x /etc/sudoers
    visudo /etc/sudoers
    

fix that mistake and be happy :)

2
  • While pkexec solution suggested by @eliah-kagan seems to be easier, this one is more universal. On my machine it turned out that there is no pkexec installed and of course I could not install it because sudo apt-get install pkexec somehow did not work.
    – running.t
    Oct 15, 2015 at 14:06
  • Also within this approach I would use visudo instead nano /etc/sudoers.
    – pa4080
    Dec 3, 2018 at 12:38
9

If you messed up your sudoers file, you'll need to:

  • Reboot into recovery mode (hit escape during boot, choose the recovery mode option on the grub screen)
  • Choose the 'Enable networking' option (if you don't your filesystem will be mounted as read-only. who knew)
  • Chosee the 'Drop to root shell' option
  • run visudo, fix your file
  • Reboot with normal grub option

source :- http://mario.net.au/content/recover-etcsudoers-ubuntu-1204

1
  • Hi, does it removes the iptables, files of existing system ? May 24, 2018 at 7:48
6

For WSL users, accessing a bad sudoers is much more straightforward:

wsl.exe -u root visudo

If you cannot recover the file manually this way, you can reset it to the default installed version (adapted from this answer) with:

wsl.exe -u root -e apt install --reinstall -o Dpkg::Options::="--force-confask,confnew,confmiss" sudo

Important: This will reset all configuration files associated with sudo, including other customizations done in /etc/sudoers.d.

5
  • Thanks for adding this aspect to the portfolio of answers. 👍 Sep 8, 2022 at 15:51
  • @ArturMeinild Certainly. Would you do me a favor and let me know if my subsequent edit is okay? I'm not an apt expert, but that should force reinstallation of the sudoers files, right? Note that I did test this by deleting my own /etc/sudoers and recovering it with that command. Sep 8, 2022 at 15:57
  • I'm also not that much of an expert, but it looks right. Maybe @steeldriver can confirm? Sep 8, 2022 at 15:59
  • 1
    I confirm this saving an entire day at work 😂
    – FonzTech
    Mar 27, 2023 at 10:42
  • @FonzTech Thank you for the confirmation, and glad it worked for you! Mar 27, 2023 at 11:12
4

There is nothing wrong #include sudoer.d removing #include sudoer.d won't make any difference.

But please make sure you don't have any syntax errors. I had same issue but and spent hours to fix and just figured out they are syntax errors. Refer to manual and make them right.

For example Say your username is : dolly I used following which is wrong

 dolly ALL = (ALL) ALL NO PASSWD: ALL

correct syntax is

dolly ALL = (ALL) ALL //give permission to everything, not good

or

dolly ALL=(ALL) NOPASSWD:/usr/bin/thurderbird //good, give specific permission

hope this helps

2
  • A better approach than making sure you don't have syntax errors is to always use visudo when editing these files, which makes sure you don't have syntax errors for you, before it modifies file. visudo is not just for editing /etc/sudoers--it will also create and edit files in /etc/sudoers.d. It will also work with whatever text editor you want. See the manpage for details. Jul 3, 2012 at 0:12
  • As for giving specific permission, please note that this is only useful for very simple commands/apps, because any sufficiently complex app (including thunderbird, which should never be run as root anyway) will effectively give the user full system access when run as root. Even seemingly simple functionality opens the door to full root access. For example, a user who can run a program that can save a file to an arbitrary location as root can gain full root access (they can install their own /etc/sudoers, or if syntax limitations prevent that, they can install their own /etc/crontab). Jul 3, 2012 at 0:16
3

run recovery mode then type this

chown -R root:root /etc/sudoers.d
chmod u=rwx,g=rx,o=rx /etc/sudoers.d/
chmod u=r,g=r,o= /etc/sudoers.d/*

only the group and user root should have read privelege

2

You can also login as root on a tty console with Ctrl+Fn (Fn from 1 to 6) and run visudo.

2
pkexec visudo

then revert your mistakes

2
  • 1
    not necessary to use pkexec
    – Braiam
    Jan 1, 2014 at 12:01
  • 1
    @Braiam visudo has to be run as root. If sudo doesn't work, pkexec sometimes does. This is covered by my earlier answer... but it is a correct answer, visudo by itself (when not run as root) will not work, and there may be value in correct, brief answers even when their recommendations overlap considerably with other answers. Of course, if one goes into recovery mode, that's a root shell and then neither sudo nor visudo is necessary for commands like pkexec. Maybe that's what you mean... Mar 29, 2014 at 5:30
1

You can edit your boot entry while in grub as well.

Simply reboot your pc, and wait for grub to show. Then press "e" on the "Ubuntu" entry to edit it.

Look for a line with "linux = " or "kernel = " and simply add an "single" to the end of that line.

Then press F10 to boot this temporarily modified boot entry. This will give you a shell (without GUI) with root rights and you can edit the sudoers file with s.th. like nano /etc/sudoers back to its previous state.

Then reboot and its done.

1

In Ubuntu 16.04 running on a VirtualBox (shouldn't make a difference), the above methods didn't work for me (invalid row in the end of the file). What did work was:

  1. Restart the VirtualBox
  2. Let it boot normally, until it asks for your username & password in the console
  3. Login normally with your username
  4. Then when you end up in the console (provided your box doesn't boot into a GUI), simply give the command su - and then give your own username's password.
  5. It should now end up in root@ubuntu-xenial:~# prompt, if the /etc/sudoers isn't too broken or empty. Not sure what would happen in that case.
  6. Then you can simply run visudo and fix the file.
  7. Then Ctrl + X and it will prompt to Save modified buffer. Press Y and Enter
  8. Restart the box and it should work now.

In case your /etc/sudoers is empty or missing something, and you can edit it, then here's the contents of mine:

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

root ALL=(ALL:ALL) ALL

%admin ALL=(ALL) ALL

%sudo ALL=(ALL:ALL) ALL
2
  • Your step 4 does not make sense, it only works when your root password is same as your normal user.
    – alfred
    Aug 3, 2019 at 12:47
  • Which is very common in a local VM. Aug 3, 2019 at 16:37
1

Good practice: a backup terminal window and run sudo su there. On another termianl run visudo or sudo vim /etc/sudoers. If anything goes wrong, go back to terminal one and fix the file. You may ask, why not just run sudo su before visudo in one terminal? This works as well, but has higher risk of you closing the terminal before you know it.

1

There is a way simpler solution. Without rebooting, recovery mode, or pkgexec (pkgexec didn't work and have no idea why or how I should use it), simply do:

su root # switch to root user, without using sudo (which is broken at this point)
your_favorite_editor /etc/sudoers # e.g. nano

And then just fix the syntax error!

5
  • 1
    What's with the downvote? Worked perfectly for me.
    – rien333
    Aug 8, 2019 at 13:29
  • This answer is actually working. I wonder why the downvote !!
    – McLan
    Nov 25, 2019 at 18:48
  • 1
    I suggest that downvote should come with an explanation. Otherwise, people can exploit it and, even worse, disallow a valid answer.
    – McLan
    Nov 25, 2019 at 18:50
  • 1
    I think the downvote came from the land that running this command requires root to have a password, which by default it doesn't.
    – Ali Tou
    May 20, 2020 at 0:07
  • Ah, so the thing is that it doesn't work for ubuntu. So many questions on this board are applicable to linux in general, however, that I often fail to think about distro differences (and of course, this is the main thing that comes up on google when you search this problem).
    – rien333
    May 20, 2020 at 8:44
1

Adding this for the new wave of WSL-based Linux VMs. When I locked myself out of my debian-based WSL2 VM (Pengwin) which didn't have pkexec and the root password was not set, here's what I found fixed the problem:

  • Open a Windows Powershell as administrator (right-click 'Run as Administrator')
  • Set the default user on the VM to be root (because it won't ask for a password) per this how-to:
<distro.exe> config --default-user root

Example:

ubuntu1804.exe config --default-user root 

or

pengwin.exe config --default-user root
  • Re-launch your distro.
  • You should now be root and can go fix your sudo problem.
  • Repeat the process to set the default user back to normal.
1
  1. You can bind the /etc volume into docker like that:

docker run -it --rm -v /etc:/etc_host ubuntu bash

  1. You gained root access. Then you can change the permissions of /etc/sudoers to 777:

chmod 777 /etc/sudoers

  1. Edit, fix the file and save it with any editor:

vim /etc/sudoers

  1. Change the permissions of /etc/sudoers to default 440:

chmod 440 /etc/sudoers

That's all.

0

If you have access to reboot the server, you can reboot it and catch it at the grub prompt for Ubuntu. Press 'e' to edit the grub boot config.

Find the line that starts with linux and is indented, then go to the end of that line, and add a space then init=/bin/bash. Next press F10 to boot the server. At the root shell prompt enter mount -o remount,rw / and press enter.

Now you have access as root to modify the /etc/sudoers or /etc/sudoers.d/filename.

Once you have finished modifying the files as needed, enter reboot -f and the server will reboot as normal, and your sudo issues should be resolved.

You must log in to answer this question.