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

Question

I have run following command accidentally

sudo chown [username] -hR /

Now sudo su getting error:

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

How to Solve This?

Note: When I had this issue, I had reinstalled the OS (Because at that time on-other answers exist and I can't wait more). So, Now new answers will be no longer supported from my side! — Pandya, Jan 30 '15 at 12:18
Thanks to the tiny Warning posted under Option 1 [here](https://docs.npmjs.com/getting-started/fixing-npm-permissions) which I gladly ignored and ended up here! — Anand Rockzz, Jun 30 '17 at 09:35
Use https://medium.com/@KongToonArmy/sudo-must-be-owned-by-uid-0-and-have-the-setuid-bit-set-cdca3dba7d19 by KongToonArmy KongToonArmy — Rupsingh, Aug 20 '19 at 08:08
I wanted to answer this, its closed now, and IDK why. Its the oldest post I can find pertaining to this specific error message. Its important to note, that sometimes you can get this error message by adding 2 or more administrators to a single system. Another thing that can happen is that you could have change the permission of your binaries. In both of these situations, you could recieve this error message. Its important to note, that this error message comes the fundamental fsys, and not from distro specific software. From my understanding, this error is basically saying that — JΛYDΞV, Mar 01 '22 at 07:04
the sudo command is basically saying that sudo isn't owned by root anymore, which isn't the same as saying you are not the root user. In other words, many people that have answered this question misinterpret what it means. Every time I have encountered this issue its been realitivley easy to fix. Recently I changed an account name, but didn't want to delete my old account, so I just switched permissions for admin from the old account to the new account. I got really confused becuase I was getting this error, but quickly found out, its because I some how set both accounts as admin. — JΛYDΞV, Mar 01 '22 at 07:25
I just changed permissions for the other account, restarted the computer and everything worked. — JΛYDΞV, Mar 01 '22 at 07:26

user10962 · Answer 1 · 2020-01-21T22:57:05.903

211

As you'll read on this answer on SO, this problem is not as hard as people are making it. You can get the sudo command working again without a reinstall by following these simple steps:

Log out as the current user, then log back in as root.
Execute chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
Log out as root, then log back in as the current user.

This does the trick and is much quicker and less painful than the "nuclear option" recommended in other answers.

If your root password is not set, you can boot in Recovery Mode to set it.

Note that this will resolve the titular error /usr/bin/sudo must be owned by uid 0 and have the setuid bit set but if like the OP you did more than mess up the permissions of the /usr/bin/sudo file, a more "nuclear" option may in fact make more sense.

edited Jan 21 '20 at 22:57

answered May 24 '14 at 13:51

user10962

2,489
2
16
12

24

If you do not have a root user, restart and press Esc to enter the grub menu. There select Advanced options for Ubuntu and select recovery mode. Then select root and you can find yourself in the root shell. If you get an error that the filesystem is in read only mode, do: mount -o remount,rw / – George Oct 23 '14 at 02:25
21

Sure, that will fix `sudo`, but it isn't going to fix the dozens of other things that were broken. – psusi Jan 30 '15 at 20:57
6

Had same problem in my lxc container, additionally had to do this: `chown root:root /usr/lib/sudo/sudoers.so && chmod 4755 /usr/lib/sudo/sudoers.so;` `chown root:root /etc/sudoers;` `chown root:root /etc/sudoers;` – Aurelijus Rozenas Jul 12 '16 at 05:40
7

using `su root` instead of `sudo su`, followed by the root password can save you some headache, if your ssh, or instead of going to grub. – Brian Thomas Aug 19 '16 at 01:03
5

in addition to what @infro said I also needed `chown` for `/etc/sudoers.d`, `/etc/sudoers.d/README` and `/var/lib/sudo` – Roman Bekkiev Sep 14 '16 at 08:59
still not solved my problem: `sudo chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set` – Mr world wide Sep 20 '17 at 14:43
I was about to reinstall the whole system on my office laptop, you sir are my hero and saved me hours of work. Besides, I just learned something new – oidualc Nov 21 '17 at 08:56
2

I fixed the permissions following your instructions and everything was ok, and then I checked the security of my install with https://github.com/CISOfy/lynis what else do I need to do? just to be sure that my system has no need to be re-formated – Israel Morales Mar 24 '18 at 03:56
1

1. `su` 2. `chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo` 3. `exit` – Deepak Mahakale Aug 24 '18 at 06:12
2

Helpful tip: if you are using WSL, check out this tutorial to log in and out of root: https://www.tenforums.com/tutorials/128152-set-default-user-windows-subsystem-linux-distro-windows-10-a.html – Jacolack Aug 16 '21 at 21:35
Also helpful tip for WSL. https://askubuntu.com/questions/931940/unable-to-change-the-root-password-in-windows-10-wsl `wsl -u root` will login to wsl as root – Jay Killeen Jan 10 '22 at 03:13
That helped a lot. I would add a mention : Even after setting root password in recovery mode, it's impossible to remote SSH as root. So I did chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo directlly in recovery mode root shell. Reboot and I can use sudo with no problems via SSH as a user – Jurion Jan 02 '23 at 23:20

Oli · Accepted Answer · 2017-11-21T10:31:46.887

51

Back up your data and reinstall.

This probably looks extreme but this isn't just sudo. You destroyed the permission structure of your entire filesystem. Some of the other answers can get sudo working, but ignoring the whole problem is inviting a later disaster.

You could try to mirror the owners off another install but there are cases (/var/ for example) that are highly dependant on what you've actually got installed. If you want to get a scale of the problem, I've actually had a crack at helping somebody fix this sort of issue before. The fix is manual, long and could easily leave your system insecure or broken.

Picking through that mess is going to take considerably longer than a clean install.

This has had a couple of drive-bys from folks that don't understand the seriousness of the situation here. To them it looks like a big pile of unnecessary work, the sort of thing a rogue plumber or mechanic says to shake you down for a bigger job.

If you've only changed the permissions on /usr/bin/sudo, by all means, just fix that. But this question is about a total system change. Every file (save the runtime-only ones) are now owned by the user. Everything the user runs (eg browsers, browser exploits) could then overwrite system files, spy on you, extract any data. This needs to be corrected. Per above, this is difficult. The easiest way is a reinstall.

So please, don't be lazy about this. Filesystem permissions help keep you safe, fix them.

edited Nov 21 '17 at 10:31

answered Apr 22 '14 at 14:23

Oli

289,791
117
680
835

12

This should not be the accepted answer. Boot into recovery mode and run the commands in the following answer: https://askubuntu.com/a/471503/311767 – Tisch Jun 08 '17 at 09:35
10

@Tisch That answer fixes `sudo`. The question assumes the ***entire*** system is owned by `$USER`. Just repairing `sudo` leaves the rest of the system in a very vulnerable state. A reinstall is justified unless you want to spend hours trawling a working system to compare who system files should be owned by. – Oli Jun 08 '17 at 14:38
"doctor, my toe is hurting.. what can I do??" "Oh my dear patient, I'm afraid you will have to chop away your leg". How can this be the accepted answer? – oidualc Nov 20 '17 at 19:03
11

@oidualc Because it's the *right* answer. I'd already covered this in a previous comment and I've just added an edit. Filesystem permissions are a serious security feature. Don't be lazy about fixing this. To finish your analogy, your toe has gangrene and it's given you septicemia. You cannot see that in your delirious state, but trust me, I'm a doctor. – Oli Nov 20 '17 at 20:34
2

This answer is bogus. "su" then "chown root:root /usr/bin/sudo" – deepelement Nov 21 '17 at 00:35
@Oli I see your point and I strongly disagree. The question is "Now sudo su is getting an error. How do I solve this?". The fix is the answer right below, the workaround is this very answer and the workaround has a huuuuuge side effect. – oidualc Nov 21 '17 at 08:53
4

@oidualc You're welcome to disagree but it doesn't mean you're not still confusing a single symptom with a systemic problem. – Oli Nov 21 '17 at 10:32
1

As much as I hate to say it, this will save time in the long run. In general one should be extremely careful with `chown` and `chmod` for system directories. – qwr Aug 26 '18 at 20:16
I ran into this issue when I accidentally installed composer with sudo. The installer changed ownership of the entire /usr/local/bin/$USER folder. The fix was NOT to drop a thermal nuclear warhead on the machine, but rather just run chown root:root /usr/local/bin/sudo && chmod 4755 /usr/local/bin/sudo – Peter Drinnan Apr 26 '19 at 12:13
4

@PeterDrinnan The answer involving nuclear ordinance assumes a global chowning. Your case sounds much more discrete. That said, why on earth do you have a `sudo` binary in `/usr/local/bin/`? That seems very dodgy to me. – Oli Apr 26 '19 at 12:38
1

I have a strong feeling @Oli is right about this. Assuming you didn't just accidentally screw up permissions of the sudo binary, Chances are, you probably did something stupid like me. While in /root/, tried to RECURSIVELY set permissions for every hidden directory in that directory that was moved over from a non-root user. `sudo chmod -R root:root .*` Who knew that `..` was included in that list. Yikes! – Lon Kaut May 28 '19 at 13:00
Is it possible this is a product of being on a VPS? – THE JOATMON Jan 17 '21 at 15:38
Even if the user got permission for all directories: What problem will it create, if we just give the ownership for all directories back to root? – Tigerware May 12 '22 at 17:47
"This probably looks extreme but this isn't just sudo." should be "This probably looks extreme because it IS. It isn't just sudo." – El Ectric Aug 27 '23 at 14:57

score 21 · Answer 3 · edited Jun 12 '20 at 14:37

go to recovery mode by keep pressing Esc while booting the system.
select root option in long list you can see after entering into recovery mode (it is actually root shell)
type command - mount -o remount / (Or in recovery you can click on grub option. This helped me get read-write permissions on the file system. This basically updated the read/write mode on the file system since the command wasn't working for me initially)

It will remount your file system in read and write mode.
command - chown -R root:root /usr this command will change ownership from "user" to root again recursively
now still i had problem with sudo command, so I again followed step 1,2,3 and executed chmod 4755 /usr/bin/sudo

Now I really think that re-installing would have been really a "nuclear option"

@Hridaynath you're missing the / in usr/bin/sudo on #5 in your answer — mdo123, Feb 13 '19 at 21:52

score 9 · Answer 4 · edited Sep 27 '16 at 06:51

9

Had the same issue on my droplet on digital ocean.

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. Below are command that ive execute and reboot after.

chown -R root:root /usr/bin/sudo
chmod -R a=rx,u+ws /usr/bin/sudo
chown -R root:root /usr/lib/sudo/sudoer.so
chmod -R a=rx,u+ws /usr/lib/sudo/sudoer.so

Hope it helps.

edited Sep 27 '16 at 06:51

Tshilidzi Mudau

4,143
3
24
32

answered Sep 27 '16 at 03:09

Marvee Lou Manriquez Ventures

91
1
1

1

You don't need `-R` here. How did you manage to get permission to `chown` and `chmod` the files? – Zanna Sep 27 '16 at 05:02
without -R should be working..execute the command on my droplet console. – Marvee Lou Manriquez Ventures Sep 27 '16 at 07:27
@Zanna Digital Ocean images have root login enabled by default. – wjandrea May 09 '18 at 15:37

score 4 · Answer 5 · answered Dec 04 '14 at 13:40

4

The above methods didn't work for me, because I couldn't "log back in as root" (unknown password) But I got a root shell by editing

vi /etc/lightdm/lightdm.conf

autologin-user=root
greeter-show-manual-login=true

After rebooting I was finally able to run

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

answered Dec 04 '14 at 13:40

Anno2001

141
2

2

The "log in as root" originally said was actually "Reboot into recovery mode and pick the root shell". But as other comments have said, this only rescues the `sudo`. There are dozens and dozens of files that need the correct security which you have to manually fix. A reinstall is both quicker and more likely to fix everything. – Oli Jul 14 '15 at 08:14

score 3 · Answer 6 · edited Apr 13 '17 at 12:25

3

Unfortunately, if you do not have a full backup, probably the best thing you can do at this point is to reinstall.

Consider that you have changed all the files ownership to the same user, completely messing the security paradigm of your system....

If you search this site there are a lot of similar problems with chmod, as for example How can I recover from chmod -R a-wrx / command?

edited Apr 13 '17 at 12:25

Community

1

answered Apr 22 '14 at 14:26

Rmano

31,627
16
118
187

score 2 · Answer 7 · edited Apr 13 '17 at 12:24

I was not able to edit lightdm.conf file under running system. I fixed things like this:

boot Ubuntu live usb
mount the root partition in order to access /etc/lightdm/lightdm.conf on the installation
sudo -H gedit /mnt/etc/lightdm/lightdm.conf and add the following lines from Anno2001's answer
```
autologin-user=root
greeter-show-manual-login=true
```
reboot

run command:

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

Change back default user in /etc/lightdm/lightdm.conf (you don't want to autologin as root every time, which would be very insecure and dangerous)
reboot, and my system works fine again.

score 1 · Answer 8 · edited Aug 25 '22 at 04:53

If you have root user password then:

Login as root user
open terminal

Enter following commands:

mount -o remount /
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
chown root:root /usr/lib/sudo/sudoers.so && chmod 4755/usr/lib/sudo/sudoers.so
chown root:root /var/* && chmod 4755 /var/*

If you do not have root user password then:

Reboot your system in recovery mode(boot and press and hold esc button to enter in recovery mode)

here it looks like
Navigate to (advance option for linux) by using down arrow button and press two times Enter

here it looks like
Navigate to root by using down arrow button and press Enter

here it looks like

Now enter following commands:

mount -o remount /
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
chown root:root /usr/lib/sudo/sudoers.so && chmod 4755/usr/lib/sudo/sudoers.so
chown root:root /var/* && chmod 4755 /var/*

Press ctrl+d and then select resume option to boot normal

I'm using PopOS, so a USB disk reboot, I just corrected the permission for sudo file 4755 and all good because I knew that was the only thing I messed up. — Daniel Katz, May 15 '23 at 18:15

score 0 · Answer 9 · answered Sep 28 '22 at 07:42

0

You destroyed the permission structure of your entire filesystem - YES IT's TRUE.Entire root is corrupted. But don't panic recovery is quite simple.Create a new volume of the root disk with the latest snapshot then dettach the old volume and attach it to the instance with the same disk name.With 5 minutes downtime you can login to the server again.

answered Sep 28 '22 at 07:42

Priyanka

1

1

This answer needs way more details and some step by step instructions. – David Sep 28 '22 at 14:49

score 0 · Answer 10 · answered Jun 13 '23 at 22:36

This applies to those environments where they have docker / Kubernetes environment running and has host root file system is mounted into the container / pod.

kubectl exec -it mypod -- chown root:root /host/usr/bin/sudo && chmod 4755 /host//usr/bin/sudo

I have not tried creating a fresh Kubernetes pod but I guess that should work too.

score 0 · Answer 11 · answered Jun 26 '23 at 13:31

For those who does not have the root password, but who do have docker installed, here is a one-liner:

docker run -v /:/target bash bash -c "chown root:root /target/usr/bin/sudo && chmod 4755 /target/usr/bin/sudo"

Since the docker image run as root, you are root in the image. The volume mounted allow you to change your root structure. The command allow you to fix your sudo.

PS: imagine what else you could don without root permission and a docker...

score -2 · Answer 12 · answered May 04 '16 at 14:07

-2

I have changed /usr/lib/ to root owner but but sudo only executes with root login in the terminal.

step one: su root step two: cd /usr/lib step three: chown -R root:root sudo

and that is it. Just NOTE you have tu run su root every time you want to use sudo.

answered May 04 '16 at 14:07

Cyprian Maina

1

2

except Ubuntu has disabled root access by default so you can't `su root` – Zanna Jan 02 '17 at 08:26

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

12 Answers12

Linked

Related