🚨 Linux Error Guide: 'sudo: must be owned by uid 0 and have the setuid bit set' — Restore sudo

Overview

sudo refuses to run and prints this the moment its own binary no longer has the permissions it requires to escalate privilege:

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

A closely related variant appears when the setuid bit is intact but the effective UID is wrong, or when the sudoers file/directory permissions are unsafe:

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

This is a hard failure: sudo will not elevate at all, so the obvious fix — sudo chmod/sudo chown on sudo itself — is impossible. You must escalate by another path first.

Symptoms

• Every sudo command fails immediately with the ownership/setuid message.
• ls -l /usr/bin/sudo shows an owner other than root or a missing s in the permission bits.
• The failure appeared right after a recursive chmod/chown, a botched backup restore, or mounting the filesystem nosuid.
• sudo -l and even sudo -v fail the same way — you cannot get a root shell through sudo.

Common Root Causes

• A recursive chmod -R or chown -R hit /usr. A stray chmod -R 755 / or ownership sweep strips the setuid bit or changes the owner of /usr/bin/sudo.
• Setuid bit cleared. chmod 0755 instead of 4755 removes the s bit sudo depends on.
• Wrong owner. The binary is owned by a non-root user after a restore or rsync that didn’t preserve ownership.
• Filesystem mounted nosuid. /usr or / remounted with nosuid disables all setuid binaries, sudo included.
• NFS root without root privileges. sudo sits on an NFS export that squashes root (root_squash).

Diagnostic Workflow

You cannot use sudo, so first inspect the binary directly. Expected is owner root, mode 4755:

ls -l /usr/bin/sudo
stat -c '%U %A %a' /usr/bin/sudo    # want: root -rwsr-xr-x 4755

Check the mount options for the filesystem holding it:

findmnt -no OPTIONS -T /usr/bin/sudo
mount | grep -E ' / | /usr '        # look for nosuid

Verify the package’s expected permissions to compare against reality:

dpkg -s sudo 2>/dev/null | grep -i status      # Debian/Ubuntu
rpm -Vf /usr/bin/sudo                            # RHEL: shows perm/owner drift

Confirm you have an alternate escalation path before you break anything further:

which pkexec doas su
grep -c '' /etc/passwd    # is a root password set / usable?

Example Root Cause Analysis

An operator ran chown -R appuser:appuser /usr/local but, due to a shell variable that expanded to empty, actually executed chown -R appuser:appuser /usr on a production box. Immediately every sudo returned “must be owned by uid 0.”

stat -c '%U %A' /usr/bin/sudo confirmed the owner was now appuser and the mode had lost its setuid s bit. With sudo unusable, the fix came through pkexec (PolicyKit), which was still setuid-root: pkexec chown root:root /usr/bin/sudo && pkexec chmod 4755 /usr/bin/sudo. On hosts without pkexec, the same repair is done from single-user/rescue mode where you are already root.

A follow-up rpm -Va | grep -i /usr/bin (RHEL) revealed dozens of other binaries whose ownership had been changed, so the team restored the full /usr ownership from package metadata rather than fixing sudo alone.

Prevention Best Practices

• Never run recursive chown -R/chmod -R against /, /usr, or /bin; scope them tightly and echo the target first.
• Keep a second escalation path available — a root password, pkexec, or console/rescue access — so a broken sudo is never a lockout.
• Restore backups with ownership and permissions preserved (rsync -a, tar -p), and verify setuid bits afterward.
• Mount /usr and / without nosuid; apply nosuid only to data partitions like /home and /tmp.
• Periodically audit setuid binaries with rpm -Va / dpkg --verify so silent permission drift is caught early.

Quick Command Reference

# Inspect (no sudo needed)
stat -c '%U %A %a' /usr/bin/sudo
findmnt -no OPTIONS -T /usr/bin/sudo

# Repair via PolicyKit if pkexec is intact
pkexec chown root:root /usr/bin/sudo
pkexec chmod 4755 /usr/bin/sudo

# Repair from a root shell (su or single-user / rescue mode)
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo

# Fix a nosuid mount
mount -o remount,suid /usr

# Verify against package metadata
rpm -Vf /usr/bin/sudo        # RHEL
dpkg --verify sudo           # Debian/Ubuntu

Conclusion

This error means sudo’s own binary lost the two things it must have to escalate: root ownership and the setuid bit (or its filesystem was mounted nosuid). Because you cannot fix it with sudo, escalate through pkexec, su, or single-user mode, then restore root:root ownership and mode 4755. The real lesson is upstream: keep recursive permission changes far away from /usr, and always keep a second path to root so a slip never becomes a lockout.