Sudo command is not working

We have designed the custom carrier board for jetson nano (production version SoM )

We build 15 PCB’s flashing process completed working fine but currently, we are facing an issue as sudo commend is not working.

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

Please help me to solve the problem.


Not sure, but it reminds me an issue when building rootfs on Windows filesystem rather than Linux ext4 fs.
If you were using a VM from Windows, but sure to use a partition with linux filsesystem for building the jetson linux rootfs.

1 Like

Dear NVIDIA team,

We are only using a partition with linux filsesystem for building the jetson linux rootfs.


Just to expand on what @Honey_Patouceul mentions, the rootfs is itself first stored on the host PC. Then an image is generated from that content, and this image gets flashed. The content on the host PC for the rootfs as a whole would be at:

On a booted Jetson the “sudo” command would be at “/usr/bin/sudo”. If you use verbose ls on this, then the permissions must show like this, or else sudo will refuse to work:

# ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 136616 Jan 31  2020 /usr/bin/sudo*

Note the leading “-rwsr-xr-x”. That “s” SUID bit is very important. Non-Linux filesystems (well, many filesystems which are based on *NIX standards also work just like Linux) have no capability to store that permission bit. If you look at your host PC and check the filesystem type, and it turns out to be something other than ext4, e.g., NTFS, then there is no possibility of a valid flash (the flash would work, but the content would be wrong). What type of filesystem exists for “rootfs/”? See:
df -H -T ~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/rootfs/

Also, verify on the host PC that the content to be flashed has correct permissions (correct permissions were listed above from the Jetson side, this is for the host side):
ls -l ~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/rootfs/usr/bin/sudo

If sudo permissions are wrong on the host PC (and very likely they are wrong), then either (A) your host PC is using a non-Linux filesystem, or (B) sudo was not used to unpack the content (only root can preserve SUID bits). Normally, for the latter case, SDKM would have asked for the sudo password on the host PC, but if manually installing, or prior to an actual flash, content might be unpacked incorrectly.