I've written a script that copies some files from one place to another and since I don't have permissions to the source folder, I tried running it with sudo. The problem is that now the creation of the destination folders fails. Here is a simple test case:

In my home directory the following works:

mkdir testDir

But this fails due to permission denied error

sudo mkdir testDir2

My home directory has 755 permissions and is own by me.

I ran sudo groups and found that as expected the root group is there, but strangely, the users is not. Also running groups as myself reveals that I'm not in the sudo group.

Any ideas what's going on? Why am I not able to write to my home folder when running with sudo?

  • 1
    first idea that comes to mind is that your home directory is on an NFS share that's squashing root – Jeff Schaller Nov 14 '16 at 19:59
  • Yes, it is an NFS. Can you explain how could root be squashed on an NFS share? The only thing I can think of is to mount the share read only, but that's certainly not the case. – ventsyv Nov 14 '16 at 20:09

This is due to "root squash" on the NFS server. From the exports(5) man page (emphasis mine):

nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called 'root squashing') is the default, and can be turned off with no_root_squash.

To paraphrase, it's generally a security risk to allow root (e.g., when running sudo) on the NFS client to modify files and file attributes as if it were root on the NFS server. This would effectively make root on the client equivalent to root on the server, and allow a rogue client to take over the server.

From the RHEL 6 security guide:


Your Answer

