Error: sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

[davetropeano]

Last night I installed nodejs and did a sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share} to allow for npm install -g without needing sudo. I was able to install the express, express-generator, and strongloop packages just fine.

This morning I went to do a pip install pdfx and got the usual message about not having permissions to /usr/local/lib/python2.7 so I tried to chown that directory and got the error:

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

sudo no longer works for any command and from what I can read there is no way to log into WSL as root to patch the sudoers file and make sure persmissions are properly set on /usr/bin/sudo.

[benhillis]

It looks like one of your earlier chown commands must have modified the mode of /usr/bin/sudo. You can change the default user to rot by using:

lxrun.exe /setdefaultuser root

This is mentioned in our mentioned in our MSDN documentation.

[davetropeano]

Thank you. It is odd though that a chown -R /usr/lib/... would modify the mode of sudo, no?

[aseering]

"mode" is sometimes broadly defined to include "owning user". (I assume that's what @benhillis meant.)

Especially for binaries such as sudo which have the sticky bit set in their actual mode byte, which means that, regardless of which user executes them, they run as the user that owns the binary in the filesystem. (sudo is supposed to always run as root; it then checks the user who launched it and it checks what they asked to do, and it determines whether they're allowed to do it, whether they have to type a password first, etc.)

[benhillis]

In addition to the standard read / write / execute and type bits three additional bits that can be set in the files mode. The sticky bit, the set-user-id bit, and the set-group-id bit. When a file that has the set-user-id bit set is exec'ed it will inherit the uid of the file owner. For example, sudo is owned by root so it will be run as root instead of the uid of the current thread.

@davetropeano the chown -R /usr/lib/... command shouldn't have stripped this bit. Do you have an exact sequence of the commands you ran to get you into this state that I could try locally and see if we have a bug somewhere?

https://en.wikipedia.org/wiki/Setuid#SUID

[davetropeano]

Bingo - I found the problem...

sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}

does not work here since the npm config is in /usr and NOT /usr/local when you install using apt-get. So... the ownership was extended to /usr/bin -- which of course impacts sudo.

[benhillis]

@davetropeano Good catch, that definitely looks like what caused this.

[ojengwa]

@benhillis Just ran into the same problem but on Azure (Ubuntu). Can't seems to fix it with the help I got online since the seems to depend on the sudo command.

Any helps? PS: Sorry for calling you, sir. :)

[benhillis]

@ojengwa - Can you please clarify what you mean by Azure Ubuntu? Are you using Windows Subsystem for Linux?

[crcrewso]

@benhillis there is an ubuntu server in the Azure marketplace. I assume that means an Ubuntu VM running in the Azure infrastructure.

[lamirev]

@davetropeano Have you resolved the problem. I'm still stuck after reading the whole thread. Any other helpful information ?

[garytube]

@lamirev open cmd and set root as default

lxrun.exe /setdefaultuser root

open bash - you should be root - as root do:

chown root:root ~/usr/bin/sudo && chmod 4755 ~/usr/bin/sudo

login into your user - sudo should work now

[diogofgr]

I had this problem on Win10 build 17763 with Ubuntu 18.04. On my Windows version there is no lxrun.exe so, adapting @garytube 's solution, I did the following:

1 - on an elevated CMD change default user to root: ubuntu1804.exe config --default-user root

2 - open bash (zsh in my case) and change ownership: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

3 - on an elevated CMD change default user back to my username ubuntu1804.exe config --default-user [my_username]

Then I could use sudo commands again! 🎉

[ghost]

Diogofgr's solution works for me. Thank you so much

[rahul-s20]

First of all we will get an error which will show : “sudo /usr/bin/sudo must be owned by uid 0 and have the setuid bit set aws. This means the sudo root permission has been over written, which creates restriction of using sudo and it leads you into problems like all the root access you lost and getting back from this situation is not a one way solution , so lets take a look and try to back track :

1. Do not forget to create a back up using AMI or snapshot
2. Create a totally new instance and detach the effected volume from the last instance attach it back to the newly created instance.
3. Login to new instance and create a new folder in the root, and start operation as root.
4. Now time to check the attached drive in new instance : “mount”…… “fdisk -l | grep Disk”.
5. Create new folder in root directory : “mkdir /newfolder”
6. Now mount the vol : “sudo mount /dev/xvdf1 /newfolder/”
7. After mount if we check the permission we will see that the newfolder permission got changed after mounting because of the effected volume:
8. Now we can change the permission of the mounted drive by default into root under root groups : “chown -R root:root newcopy/”, after the operation if we check the permision it will be root. After this permission we have to follow the same steps to change other’s permission inside the folder, newcopy/usr/bin/ : “chmod 4755 sudo”.
9. After all the operation we have to detach the vol and attach that to the last volume

[Dutch77]

Diogofgr's solution + this: chmod 775 -R /etc/sudoers chmod 775 -R /etc/sudoers.d/

fixed sudo for me

[vinayakmajagaonkar]

I had this problem on Win10 build 17763 with Ubuntu 18.04. On my Windows version there is no lxrun.exe so, adapting @garytube 's solution, I did the following:

1 - on an elevated CMD change default user to root: ubuntu1804.exe config --default-user root

2 - open bash (zsh in my case) and change ownership: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

3 - on an elevated CMD change default user back to my username ubuntu1804.exe config --default-user [my_username]

Then I could use sudo commands again! 🎉

Thanks! That worked perfectly fine... I've had ubuntu2004 as my exe!!!

[thanos1983]

I had this problem on Win10 build 17763 with Ubuntu 18.04. On my Windows version there is no lxrun.exe so, adapting @garytube 's solution, I did the following:

1 - on an elevated CMD change default user to root: ubuntu1804.exe config --default-user root

2 - open bash (zsh in my case) and change ownership: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

3 - on an elevated CMD change default user back to my username ubuntu1804.exe config --default-user [my_username]

Then I could use sudo commands again! 🎉

It might worth mentioning that on PowerShell you do not need to run it as admin, simply run it like this: ubuntu.exe config --default-user root

Once you fix the permissions on all files you can verify if the user can switch by simply run: su - <my_user>. If no errors appear everything will work just fine, alternatively fix the permissions on any other dir that might appear and apply at the end: ubuntu.exe config --default-user <my_user>

[hltdev8642]

I had this problem on Win10 build 17763 with Ubuntu 18.04. On my Windows version there is no lxrun.exe so, adapting @garytube 's solution, I did the following: 1 - on an elevated CMD change default user to root: ubuntu1804.exe config --default-user root 2 - open bash (zsh in my case) and change ownership: chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo 3 - on an elevated CMD change default user back to my username ubuntu1804.exe config --default-user [my_username] Then I could use sudo commands again! 🎉

It might worth mentioning that on PowerShell you do not need to run it as admin, simply run it like this: ubuntu.exe config --default-user root

Once you fix the permissions on all files you can verify if the user can switch by simply run: su - <my_user>. If no errors appear everything will work just fine, alternatively fix the permissions on any other dir that might appear and apply at the end: ubuntu.exe config --default-user <my_user>

---

this worked for me so thank you :] , however I did have to change it a little:

1) on an elevated cmd prompt: wsl.exe -u root

2) chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

This was nice because then you don't have to mess at all with the default user (and it seemed to work just the same)