1

We have a problem when using NFS. We can't write into a directory on NFS client machine if that directory was created on NFS server. The reason seems to be a file/directory permission and user mapping.

Our setup:

We have 2 EC2 nodes - Ubuntu 16.04.2 LTS

NFS server installed on one machine:

ubuntu@master:~$ less /etc/exports
/home/ubuntu/data *(rw,no_subtree_check,sync,insecure)

The same dir is mounted on another machine:

sudo mkdir /home/ubuntu/data
sudo mount -t nfs masterIp:/home/ubuntu/data /home/ubuntu/data

A problem we have:

When we create a dir in NFS in a master it's created like this:

# sudo mkdir /home/ubuntu/data/Test
# sudo ls -all /home/ubuntu/data
drwxr-xr-x  2 root  root       4096 Jul  5 07:19 Test

Master has no issues accessing this directory, creating file insideeetc. But when we try to create a file from a slave node inside of Test dir, we have got Permission denied error.

When we create a dir from a NFS client machine it looks like this:

# sudo mkdir /home/ubuntu/data/Test2
# sudo ls -all /home/ubuntu/data
drwxr-xr-x  2 root  root       4096 Jul  5 07:19 Test
drwxr-xr-x  2 nobody nogroup   4096 Jul  5 07:21 Test2

So it seems NFS client's root user is mapped to nobody@nogroup when writing to NFS directories and thus can't write to directories created by root user on NFS server. We need to map a NFS clinet's root user to NFS server's root user so both of them can work freely with directories no matter where they we created.

3

Use the no_root_squash option in your /etc/exports entry. From the manual page for exports:

User ID Mapping

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.