# NFS mount readable but not writable

I'm trying to mount a remote directory owned by www-data to a local directory owned by sam.

From sam's home directory, I've created ~/directory, and when I "mount directory", I see the contents of the remote /path/to/directory, and all file ownership correctly shows as www-data:www-data in the mounted directory.

The permissions of the files in the remote directory are 775 for directories and 664 for files; and user 'sam' is a member of the 'www-data' group on the client side. As user 'root' on the client side, I am able to write changes to the remote /path/to/directory because of "no_root_squash". However, as user 'sam' I am not able to make any changes inside ~/directory.

Here is the server-side info:

in /etc/exports:

/path/to/directory my.client.host(rw,sync,no_root_squash,no_subtree_check)


in /etc/default/nfs-kernel-server (everything else is default):

RPCMOUNTDOPTS=--manage-gids


in /etc/default/nfs-common: (all defaults)

Here is the client-side info:

in /etc/fstab:

my.server.host:/path/to/directory/    /home/sam/directory  nfs rw,noatime,auto  2       0


Since the root user can make changes when the no_root_squash flag is set, I know I'm close and that the problem is not related to DNS or network or firewalls or portmapper or any of the other underlying helper libraries.

Can anyone spot what I'm missing?

-

## migrated from stackoverflow.comJun 9 '11 at 21:06

This question came from our site for professional and enthusiast programmers.

Just some more notes: I have confirmed that user 'sam' can modify files of group 'www-data' outside of the mount, and user 'sam' is a member of only 4 groups including www-data (not > 16) –  Rob Bailey Jun 9 '11 at 20:53
The answer was that although my users were added to the appropriate group on the client side, they also had to be added to the right group on the server side; and the UID of the user on the client side had to match the UID on the server side. Once I added the users to the server side and assigned them to the group on the server (and restarted nfs-kernel-server), the problem was fixed. I know this can be handled using idmapd, but I chose not to use it in this case. Hope this helps somebody. –  Rob Bailey Jun 13 '11 at 19:19