Sudoers file syntax error on WSL

Question

So, I've messed up my sudoers file in the windows subsystem for linux. I was trying to add something, and the guy of the tutorial said to edit sudoers file with nano/vim, and that's what I did (later I discovered that you should only edit it with visudo, nice). When I saved, I realized I couldn't use "sudo" anymore, the terminal would complain saying:

>>> /etc/sudoers: syntax error near line 33 <<<
sudo: parse error in /etc/sudoers near line 33
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

I've read a bunch of articles saying that I would have to run:

pkexec /usr/sbin/visudo

But the result was always the same:

Error getting authority: Error initializing authority: Could not connect: No such file or directory

I tried everything, spent like two hours reading stuff and couldn't do anything. Can anyone help me? As you can see, I'm clearly new when it comes to real linux.

Solution 1

I found quite a simple solution for my case.

Just open Windows console (cmd), then:

wsl -u root visudo

And fix the file.

Note that visudo does not catch all errors. To avoid getting locked out of sudo, keep a root shell (sudo -s) or visudo open until after you've thoroughly tested your new config.

Solution 2

On my side because the command wsl -u root visudo did not worked, I used the following alternative:

I changed the default user to be root by following the instruction in this answer:

ubuntu config --default-user root

then restart LxssManager service (from services.msc)

When I open the WSL, by default is connect as root and I can safely execute the command visudo from that WSL instance.

I corrected the bad entry and saved it.

My WSL was starting fine after the correction.

Just in case, here is the default sudoers file I had in the beginning:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification
%sudo ALL=NOPASSWD: /sbin/start-stop-daemon
%sudo ALL=NOPASSWD: /etc/init.d/ssh

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d

It's possible that some entries have been added by "apt install" command.

don't forget to switch back to the original user after the operation:

ubuntu1804.exe config --default-user <username>

The command ubuntu1804.exe can be adapted to your distro (20.04, others linux, etc...)

Comments

[Kulfy]

You must make non-root user back as default.

[NotTheDr01ds]

Hi @Sajid-Ali. Welcome to Ask Ubuntu. While I appreciate your attempt, yours is really a duplicate of the first answer (with 23 upvotes). The correct command (wsl -u root) is listed in that answer. Yours does the same thing, but with more effort, using an older command (ubuntu1804) that Microsoft doesn't recommend be used any longer.

[NotTheDr01ds]

Also, for @Kulfy who edited it - Even if you do use the ubuntu commands, you have it backwards (sort of). The ubuntu command is used if you just installed the "Ubuntu" (latest version) from the Microsoft Store. Depending on when you installed the latest, this might be 16.04, 18.04, or 20.04. However, it's also possible to install a specific version from the Store, like ubuntu1804 or ubuntu2004. The reason is that these are all just "App Execution Aliases". This is one reason that Microsoft created the replacement wsl.exe command, which is one that should really be used now.

[NotTheDr01ds]

Thank you for your answer, but for future readers' sake, please, please don't do this. Even if it "works", it's bad practice for at least four reasons. First, but least importantly, it only "works" on WSL1, not WSL2 (the WSL2 filesystem is stored in a virtual .vhdx disk image). Second, you should use visudo instead of editing the file directly.

[NotTheDr01ds]

Next, you should avoid editing Linux files (which use Unix-style LF line-endings) with Windows tools (which typically create and edit files with incompatible CRLF line-endings). While Notepad++ is smart enough to handle some cases, I've still seen a number of questions raised here on the Stack Exchange Network where problems were caused by creating or editing Linux configuration files in WSL with Notepad++ or other Windows tools. The only Windows tool that I would consider safe for this would be Visual Studio Code, when launched from within WSL.

[NotTheDr01ds]

Finally, and most importantly, (copying from Microsoft's advisory) There is one hard-and-fast rule when it comes to WSL on Windows: DO NOT, under ANY circumstances, access, create, and/or modify Linux files inside of your %LOCALAPPDATA% folder using Windows apps, tools, scripts, consoles, etc. Opening files using some Windows tools may read-lock the opened files and/or folders, preventing updates to file contents and/or metadata, essentially resulting in corrupted files/folders.

[NotTheDr01ds]

"in my case I found that easier than just re-installing everything" - The highest voted answer on this page avoids installation, and is safe. I'm glad it worked out for you, but future readers here should not follow your example.

[NotTheDr01ds]

Actually, the first answer did give the file, but since modifying it directly is considered bad practice, the mods agreed to an edit to remove that from the answer. The visudo command edits that very file, but does so much more safely. Also, the wsl -u root will still work when the sudoers file is corrupted.

[NotTheDr01ds]

Really should be a new question, because that wouldn't be a sudoers problem, but if you have problems with your root's bash configuration that prevent you from launching WSL normally, then you could still run apps using the wsl -e (a.k.a. wsl --exec) as the shell, rather than in the bash shell. So several options, including wsl -u root -e sh (to run the dash shell (without going through bash), or wsl -u root -e vi /root/.bashrc (a possible cause of the problem), or wsl -u root -e sh -c 'vi ~/.bashrc'.

[NotTheDr01ds]

Googled bin/bash invalid option gnu long option. The first result was this answer. Most likely cause for that particular error is that the script (likely .bashrc) ended up with DOS line endings ...

[рüффп]

On my side it worked but I had to restart LxssManager service in order to make the change user to be effective when switching to root, otherwise it still connect with the previous user.

[Antoine Wils]

I just tested this solution on WSL2 and it worked. Thx!

[рüффп]

@AntoineWils thanks for your comment, this solution works for both but the accepted answer is quicker. I wrote this answer because before WSL 2, the powershell command wsl.exe was not compatible with the accepted answer. I also edited this answer in order to prevent the modification of the linux file from Windows as mentioned in the (now deprecated) comments.