TLDR: I am running Ubuntu 18.04 with i3 and I messed up my permissions. Whenever I run a command with sudo, I get this error message, sudo: /usr/local/bin/sudo must be owned by uid 0 and have the setuid bit set. I am trying to figure out if I need to fully re-install Ubuntu or if this can be fixed in a less drastic way.

What had happened was: I was trying to upgrade my npm version with nvm and the nvm command was not being recognized. I followed this stackoverflow post's instructions https://stackoverflow.com/questions/21215059/cant-use-nvm-from-root-or-sudo to copy the version of node I had active via nvm into the /usr/local. I ran the below. (Yes, I realize now that I should have investigated this series of commands before running them.)

n=$(which node); \
n=${n%/bin/node}; \
chmod -R 755 $n/bin/*; \
sudo cp -r $n/{bin,lib,share} /usr/local

I then got tons of errors saying chmod: changing permissions of '/usr/bin/*': Operation not permitted

After that I ran sudo nvm install-latest-npm and got the same error as I had before, sudo: nvm: command not found.

Then I tried running another command with sudo, and got the error sudo: /usr/local/bin/sudo must be owned by uid 0 and have the setuid bit set. I now get this error whenever I run anything with sudo.

I think this problem was caused by me running chmod -R 755 $n/bin/*; \ but I'm confused because the error message said permissions for /usr/bin were not changed.
I have a two-part question: 1) What caused this error? Am I correct that it was caused by the chmod -R command? 2) Can I fix this without completely reinstalling ubuntu? If so, how?

For context, I already read these two questions sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0 and this /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. However, I am not sure if the advice from the first question's answer applies to this situation, because the error message I receive is not referring specifically to /usr/lib/sudo/sudoers.so.

Thanks for reading!


3 Answers 3


must be owned by uid 0 and have the setuid bit set

  1. Check the current owner and permissions with ls -l /usr/bin/sudo. It should similar to:

    -rwsr-xr-x 1 root root 157192 2018-08-23 10:36:40 /usr/bin/sudo

  2. Run pkexec bash in a terminal to get a shell with root permissions.

  3. Fix ownership of the file:

    chown root:root /usr/bin/sudo
  4. Set the setuid bit:

    chmod u+s /usr/bin/sudo
  5. sudo should now be available for you to make further repairs.

  • Pretty good thinking! Back when I wrote my answer I didn't even know about pkexec. I sure do now! Great answer!
    – Terrance
    Jan 9, 2019 at 14:28
  • @xiota Thank you for this very thorough response. When I checked the current owner and permissions, it was extremely similar to what you showed, -rwsr-xr-x 1 root root 149080 Jan 17 2018 /usr/bin/sudo. However, when I ran pkexec bash, I got an error message, pkexec must be setuid root. Since I wasn't able to get a shell with root permissions, I am going to boot up in recovery mode and run the suggested commands from a shell in root mode there. I will let you know if that approach works.
    – ByteByByte
    Jan 10, 2019 at 3:22
  • While you are fixing sudo, you probably need to fix pkexec too.
    – xiota
    Jan 10, 2019 at 3:28
  • I ran the commands you listed from a root shell in recovery mode. Unfortunately, I still can't use sudo or pkexec outside of recovery mode, and I get the same error messages as I did previously. What should I do to fix pkexec? (I tried googling this but didn't find anything helpful)
    – ByteByByte
    Jan 10, 2019 at 3:54
  • probably whatever you did did too much damage, and you'll need to reinstall.
    – xiota
    Jan 10, 2019 at 4:15

In your error message, it says it is coming from /usr/local/bin/sudo which is not the normal location for sudo on most Linux distributions including Ubuntu so I am guessing that you have attempted to compile and install a new, non-distribution provided copy of sudo. As /usr/local/bin is often put in $PATH before the normal /bin and /usr/bin folders, this will take precedence. Try using the normal sudo command by running /usr/bin/sudo or /bin/sudo with it's full path instead of just typing sudo. If this works, then I suggest removing /usr/local/bin/sudo unless you intend you use your customized version of it. In case you do, make sure you fix it's permissions:

chmod u+s /usr/local/bin/sudo
chown root:root /usr/local/bin/sudo

If you find a "sudo" binary in /usr/local on a package managed (you are not running something like Linux From Scratch, you are not using a secondary, dependency-resolving source build system like pkgsrc), mainstream linux system and you didn't explicitly take steps to compile a local version of sudo....

Assume malice. This looks like a (probably unsuccessful) attempt at a security compromise.

Debian or ubuntu packages will NEVER install binaries, let alone SUID/SGID stuff, in /usr/local. Any other installers shouldn't install anything anywhere that can be mixed up with system binaries like that, unless they are explicitly for that purpose (of installing a custom system binary).

Get that suspicious binary out of the way, examine what it really does, and where it came from.

As a first step, compare size and md5sum of that binary with your regular sudo binary, to establish if it is just a copy of that system binary in a stupid place.

If not ...

Does anything you manually installed clearly and openly state it installs that thing in the documentation?

If not ...

Don't trust that system until you found out what happened.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .