Can't find a user in the sudoers file

I have a Jetson Xavier running 31 (release), REVISION: 1.0, GCID: 13195123, BOARD: t186ref, EABI: aarch64 and after an update I don’t seem to be able to run any accounts with sudo. I have an nvidia account and an ubuntu account, but in both cases I get an error that neither of them are in the sudoers file. Normally I’d just boot into single user mode, or boot off of a USB drive, but I’m not sure I can do either of those on this dev kit.

So, is there a different account I should use, or an enabled root login? I’m a little stumped.



The account created on first boot should be able to sudo. If your “/etc/sudoers” file shows “group” of “admin”, then any person with “admin” group membership can sudo without specifically being named in “sudoers”. As an example, see who is in “admin” group:

grep adm /etc/group

Do beware that some errors are not from membership. Sometimes a system is flashed from a host PC which is not using a native Linux filesystem type during the flash, and as a result anything with permissions not understood by other operating systems will fail…and this includes the actual “sudo” command. What is the exact error? What is the filesystem type on the Jetson (use “df -H -T /” to find out)?

So, I have an adm group with syslog, ubuntu, and nvidia in it, but I still can’t get past the sudo error. I installed a third party server app on here too and I wonder if it didn’t decide to tinker with groups or the sudoers file for “security.”

Is there a way I can boot into single user mode, or access the linux file system from recovery?

That’s a good tip about the host PC flashing. I’m using the filesystem that the dev kit shipped with, but I’ll keep that in mind if I get desperate and need to flash the whole thing.


My mistake, “adm” is correct instead of “admin”. Those users should succeed with sudo.

What is the exact error? It is possible that a third party app altered something and security is refusing the alteration, but there are other reasons as well why this might occur. A specific error message is important for this case.

On the Jetson, what do you see from “df -H -T /”?

nvidia@iew-xavier-beta:~$ df -H -T /
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 30G 12G 17G 41% /

nvidia@iew-xavier-beta:~$ sudo ls
[sudo] password for nvidia:
nvidia is not in the sudoers file. This incident will be reported.

ubuntu@iew-xavier-beta’s password:
Connection closed by port 22

I can’t cut and ptaste the error, but if I log into the console error about not being in the sudoers file is the same for the ubuntu user.

You have a genuine mystery issue here. You already verified that users “ubuntu” and “nvidia” are in group “adm” within “/etc/groups”. This probably won’t reveal anything interesting, but as users “nvidia” and “ubuntu”, if you run the command “groups”, does this too list group “adm” for them?

Your ext4 filesystem type is good to go, and the actual error message implies it isn’t a failure of the sudo command itself not being suid root. This tends to imply that “/etc/sudoers” or something in “/etc/sudoers.d/*” is at fault, and this may be something external software did interfere with during a software install.

Normally nothing is in “/etc/sudoers.d/”, at least not by default. If something is there (other than a “README” file), then this is non-default. Is there anything in directory “/etc/sudoers.d/” other than a “README”? If so, this is of interest.

If “/etc/sudoers.d/” is empty (other than “REAMDE”), then we need to know the content of “/etc/sudoers” file.

For any of the files you find in “/etc/sudoers.d/”, and for the actual “/etc/sudoers” file, if possible, save a copy of each with a “.txt” file name extension, and upload here. These files do not contain passwsords so there isn’t any issue with posting them.

In the case that there are files (other than “README”) in “/etc/sudoers.d/”, then I suspect renaming them would be a fix, but that you won’t be able to rename due to the sudo problem. On the other hand, if we know of some new user name being added, then maybe there is a different login which will work. If no other path is available to edit or correct one of these, then there is a way to clone and restore after editing on a host PC (but this is very time consuming).