I didn't do anything on the computer except Internet for a few days and suddenly when I tried to do:
$ sudo apt-get update
I got:
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?
I have no idea what happened, last time I remember running sudo is when I did update.
sudo works with a mechanism that is called setuid (Set User ID, or also called suid). If that bit is set on an executable file (like sudo), then the application is executed under the permissions of the user, who is the owner of that file (in case of sudo, the owner is the root user).
That means, sudo is executed as root. So far so good. But, now nothing prevents you from inserting an USB-drive with a shell on it, that has the setuid bit set. You have full root access! That's why normally USB-drives are mounted with the mount option noexec, to prevent executing binary/scripts on such a device. Another mount option, if you still want to execute files, is the one that is mentioned in the error message in your question: nosuid.
See that excerpt of the mount manual page:
[...] nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. [...]
With the mount command, you can determine, if your root filesystem is mounted with that option. Just type:
$ mount
You can now remount the filesystem on-the-fly and change mount options:
$ mount -n -o remount,suid /
That sets the suid option, which is the exact opposite of nosuid.
Not really 100% related, but hear me out:
I had this problem, because I had changed the default Docker installation. And docker service wanted to execute sudo or do similar things (system calls?)
More specifically, I had moved the filesystem location where Docker installs volumes and images.
Docker Virtual machines can take a substantial amount of disk space.
Therefore I had moved /var/lib/docker to /mnt/virtualmachines_ssd/docker.
After a while I had forgotten that. I had to find out where /var/lib/docker was symlinked to.
ls -l /var/lib/docker
lrwxrwxrwx 1 root root /var/lib/docker -> /mnt/virtualmachines_ssd/docker
Indeed /mnt/virtualmachines_ssd/ was a different partition, a different filesystem.
mount | grep virtualmachines | grep sdd
/dev/sdd1 on /mnt/virtualmachines_ssd type ext4 (rw,nodev,nosuid,relatime,x-gvfs-show)
Thus,
sudo mount -o remount,suid /mnt/virtualbox_ssd
solved the problem! The "ddev" docker container was able to do its job again.
mount | grep virtualmachines | grep sdd
/dev/sdd1 on /mnt/virtualmachines_ssd type ext4 (rw,nodev,relatime,x-gvfs-show)
In your case, when you can't run sudo.
perhaps change the entry for the filesystem in your /etc/fstab, and reboot.
If you're still having this problem, or for anyone else having this problem, this was my solution (I had this problem too!).
Just reinstall sudo. Because you aren't able to use the sudo command, you'll have to escalate to a root command line with su.
$ su
Password:
#
Then
# apt reinstall sudo
No reboot necessary. You should be good to exit out of the root shell and resume you daily life.
I had this problem yesterday and I realized that the problem might be caused by a pendrive that I connected to the usb port, because the problem started soon after.
Coincidentally (or not) the pendrive had the Linux installation, even though I didn't run the executable.
So, I simply restarted the Linux and at next boot the problem vanished without a trace.
Hope it helps someone.
mountonto your question please?