Victor's room

Overview & Root Cause Summary: The error sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set is a critical Linux permission failure. It occurs when the sudo binary loses its Set User ID (SUID) permission bit (mode 4755 / -rwsr-xr-x) or is no longer owned by the root account (uid 0). This usually happens after an accidental recursive permission modification (such as chmod -R 777 /usr or chown -R user /), migration between filesystems, or tarball extraction without preserving file attributes, leaving users unable to execute administrative commands.

Understanding the Root Causes

• Stripped SUID (Set User ID) Bit: The sudo binary requires the SUID bit to temporarily elevate unprivileged user processes to root. If recursive chmod 755 or chmod 777 is executed across system directories, the SUID bit is stripped, demoting the binary to a standard non-elevating executable.
• Changed File Ownership: If /usr/bin/sudo is owned by a non-root user or group (e.g. chown user:user /usr/bin), the operating system rejects elevation for security reasons.
• Mounted Filesystem with nosuid: If the /usr partition or root volume is mounted with the nosuid mount flag, the kernel ignores SUID bits across all binaries.
• Improper Archive Extraction: Unpacking tarballs or backups without the -p (preserve permissions) or --same-owner flags resets ownership to the extracting user.

Step 1: Quick Fix Using pkexec (Without Rebooting)

If your system has PolicyKit installed (standard on desktop Ubuntu, Debian, Fedora, and Arch), use pkexec to repair permissions without rebooting.

# 1. Restore root ownership to the sudo binary:
pkexec chown root:root /usr/bin/sudo

# 2. Re-apply the SUID permission bit (4755):
pkexec chmod 4755 /usr/bin/sudo

# 3. Test if sudo is restored:
sudo whoami
# Expected output: root

Step 2: Repair Permissions via Root Shell or GRUB Recovery Mode

If pkexec is unavailable or also missing permissions, access a root shell using su or reboot into GRUB single-user mode.

# --- Method A: Using standard 'su' (if root password is known) ---
su -
# Once in root shell:
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
exit

# --- Method B: Booting into GRUB Recovery Mode ---
# 1. Reboot your system and hold Shift or Esc to enter the GRUB boot menu.
# 2. Select 'Advanced options for Ubuntu/Linux' and choose '(recovery mode)'.
# 3. In the Recovery Menu, select 'root - Drop to root shell prompt'.
# 4. Remount the root filesystem in read-write mode:
mount -o remount,rw /

# 5. Fix ownership and SUID permissions:
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo

# 6. Reboot normally:
reboot

Step 3: Fix in WSL2, Docker, and Restore Full Package SUID Bits

In containerized or virtualized environments, elevate directly from the host, and restore other corrupted system SUID binaries.

# --- In Windows Subsystem for Linux (WSL2) ---
# Open Windows PowerShell and enter WSL directly as root:
wsl -u root

# Inside the root prompt:
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
exit

# --- In Docker Containers ---
# From the host machine, exec as user 0 (root):
docker exec -u 0 -it <container_name> chmod 4755 /usr/bin/sudo

# --- Restore SUID on all system packages (Ubuntu/Debian) ---
# If recursive chmod stripped SUID across other utilities (su, passwd, pkexec):
sudo apt-get install --reinstall sudo passwd coreutils

Verification & Testing Steps

Verify file ownership, inspect the active permission mode, and confirm successful command execution.

# 1. Inspect file mode and ownership of /usr/bin/sudo:
ls -la /usr/bin/sudo
# Expected output:
# -rwsr-xr-x 1 root root ... /usr/bin/sudo
# (Notice the 's' in the user execute position, confirming SUID)

# 2. Check numeric permissions using stat:
stat -c "%a %U:%G" /usr/bin/sudo
# Expected output: 4755 root:root

# 3. Test privilege execution:
sudo -v
sudo whoami

Summary Comparison Table