sudo · sudo-rs

sudo "must be owned by uid 0 and have the setuid bit set" when the file is root and setuid

Published 2026-11-06 · HardStacked · 10 min

You type sudo and get sudo: sudo must be owned by uid 0 and have the setuid bit set (Ubuntu 26.04, which ships sudo-rs) or sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set (classic sudo). You run ls -l, and the file is exactly what the message asks for. Someone in a Server Fault question said it better than we can: "I've confirmed that both file's owner is root, and I believe the setuid has been set." Then: "What did I miss here?" (question 1154208, RHEL 8.9, Ansible Tower, 1,351 views on 2026-11-06). The usual answer is chown root and chmod 4755. If the file is already root and setuid, that changes nothing.

The message accuses the file, but it only knows one thing: sudo did not start as root. Three lines, run without root, tell you why: the file itself (the real one, because on Ubuntu 26.04 /usr/bin/sudo is a symlink), the mount that carries it (nosuid), and the identity of the process that launches it (Uid 65534, a user namespace). On Ubuntu 26.04, sudo-rs does not even look at the file: it prints this message whenever it starts without root, whatever the reason, except "no new privileges". On a nosuid mount, the old sudo said nosuid; sudo-rs blames the file.

Measured on a fresh Ubuntu 26.04.1 LTS virtual machine (arm64, official cloud image), sudo-rs 0.2.13-0ubuntu1.2, sudo 1.9.17p2-1ubuntu3.2 (installed alongside as sudo.ws), systemd 259.5, on 2026-11-06. The user is an ordinary admin: group sudo, with a password.

01. What the message claims, and what sudo actually knows

First, which sudo do you have, and what is it really?

First trap: on 26.04 the plain ls -l shows lrwxrwxrwx, no s anywhere, and that is normal. It tells you nothing about the bit. ls -lL follows the link and shows the target.

The code says what sudo knows. In sudo.ws (src/sudo.c), when the effective UID is not 0, it checks three things in this order. If the no_new_privs flag is set, it prints the "no new privileges" message. Otherwise it calls stat() on its own binary: owner not 0, or no setuid bit, prints our message. If the file is fine, it prints effective uid is not 0, is … on a file system with the 'nosuid' option set or an NFS file system without root privileges?. So classic sudo does look at the file, and the path in the message is the one it checked. In sudo-rs 0.2.13 (src/sudo/mod.rs, self_check), no_new_privs gives its own message, and any other non-zero effective UID gives our message, with no stat() at all. That is why the sudo-rs form has no path: sudo must be owned… is sudo-rs, /usr/bin/sudo must be owned… is the classic one.

02. Three lines that say what really blocked sudo

Nothing here needs root. Everything the demos below create lives in /opt/demo-sudo and /opt/demo-ns, and those are copies of sudo: the real sudo is never touched, and everything is removed at the end. The demos do need a working sudo (a healthy machine, or a VM). The diagnostic does not.

That is a healthy machine, line by line. The file is root root with an s. The mount options have no nosuid. The process is Uid 1000 and NoNewPrivs 0. In a failure, one of these lines changes: no s, or an owner that is not root (the bit is really gone); nosuid in the options; Uid 65534; or NoNewPrivs 1.

The last one is a different message, so it is not our case, but here it is:

If that is your message, you are inside a container or a service that sets the flag.

03. The bit really is gone: chown, chmod -R, and getting root back

A Super User question (1816624, Fedora 37, 22,205 views on 2026-11-06, no accepted answer) is the real case: the asker had run sudo chmod -R 755 /usr/bin/. There, the bit really is gone. We copy sudo into /opt/demo-sudo with the right mode as a witness, then we chown it to ourselves:

We never ran chmod. chown erased the s by itself, which is why a chown -R on /usr breaks sudo even without a single chmod.

Two things we measured on a second 26.04 VM, outside the capture. sudo chmod -R 755 /usr/bin does not break sudo-rs on 26.04: its binary lives in /usr/lib/cargo/bin and chmod -R does not follow the link. But su, passwd, mount and sudo.ws lose their bit silently. And dpkg --verify says nothing: 0 lines, and dpkg --verify passwd returns 0 while passwd is -rwxr-xr-x. man dpkg (1.23.7) is clear: "Currently the only functional check performed is an md5sum verification of the file contents against the stored value in the files database." The Super User answer uses rpm -Va on Fedora, which does see owners and modes. That is what the answer says, not something we measured.

Now, how do you repair it when sudo is the thing that is broken? The top answer on that Super User question (score 6) starts by becoming root another way: machinectl shell, systemd-run --shell or run0. On Ubuntu 26.04 run0 is there, and it goes through polkit, not through the sudo binary. Polkit's shipped rules declare unix-group:sudo (and admin) as administrators, so run0 asks for the password of a member of the sudo group:

At Password: you type your own password. The copy is root and rws again. We also tested it for real, outside the capture, on a VM where sudo-rs was broken with chmod 755: a user outside the sudo group ran run0, polkit offered to authenticate as the admin ("Authenticating as: <admin>"), and chmod 4755 fixed sudo. You need a terminal (without one, run0 says "requires interactive authentication") and the password of a member of the sudo group. On your machine, the real command is run0 sh -c 'chown root:root /usr/lib/cargo/bin/sudo && chmod 4755 /usr/lib/cargo/bin/sudo', or the path from your own readlink -f line. No admin with a password: the GRUB recovery mode should work, we have not measured it.

04. The file is fine, you are "nobody"

This is the shape of the Server Fault question. In a user namespace that maps neither you nor root, your UID becomes 65534 and root does not exist for the process. unshare -U builds exactly that:

Same file, same rws, but the owner is now nobody nogroup. With classic sudo you also get the signature line of the case:

/etc/sudo.conf is owned by uid 65534 above the message is exactly what the Server Fault asker pasted. In that question the asker's own accepted answer says Tower 3.8 isolates job execution with Bubblewrap, and the fix was to stop going through sudo in those tasks (become: false). Bubblewrap runs the job in a user namespace: that is what it does, but we did not measure it on Tower. Threads on the LXC and Ansible forums carry the same message; we did not reproduce those setups. The fix is not to run sudo from there: run it from the host, or give the container or the task the privileges it needs.

05. The file is fine, the mount says nosuid

Same file, same rws, and the filesystem ignores the bit. We mount a small tmpfs with nosuid and put both sudo there:

Both files are root and rws. Same cause, two messages: sudo-rs accuses the file, which is fine, and sudo.ws tells the truth.

This is not an exotic case. /tmp is nosuid by default on the 26.04 cloud image we used:

A sudo extracted or compiled in /tmp lands here. Other real versions: a /usr or /home mounted with nosuid, an NFS share. We also measured on ZFS (outside the capture, test pool): a dataset with setuid=off shows nosuid in findmnt and gives our message, and zfs inherit setuid <dataset> puts it back to on and sudo works again. An Ask Ubuntu question from September 2026 ("sudo must be owned by uid 0 and have the setuid bit set on ZFS installs", message without a path, so sudo-rs) looks like this case. It is a resemblance: the question gives neither findmnt nor zfs get, so we cannot say it is the cause.

The repair on our tmpfs:

06. Clean up

Not measured: macOS (where the same message exists), Fedora, WSL, Tower itself. Ubuntu 25.10 ships an older sudo-rs (0.2.8 according to Launchpad): not measured. We checked Debian 13 (sudo 1.9.16p2): same message and same /etc/sudo.conf … 65534 line under unshare -U.