9

I have a server running Debian 7 that exports an NFSv3 share, and a client running Centos 5 that accesses it. This works fine, except for one issue with permissions based on non-primary groups.

When I create a directory with 770 permissions on the server, a client user that belongs to the same group as the owner of the directory still can't access it if that group is not the user's primary group.

Any idea what the issue could be here? It works fine when the directory belongs to the primary group of the user, but not if it belongs to a secondary group.

2
  • Do the group ids match on the client and server? How many secondary groups does the user have? Commented May 28, 2015 at 9:21
  • 2
    @StephenKitt The group ids are identical on server and client, and the user only has 4 or 5 groups I think, we're not running into the 16 groups limit of NFS
    – user84873
    Commented May 28, 2015 at 9:56

2 Answers 2

5

Your issue may be related with the --manage-gids option of rpc.mountd enabled by default in debian (see /etc/default/nfs-kernel-server).

From the man page:

-g or --manage-gids

Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally (except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server. Note that the 'primary' group id is not affected so a newgroup command on the client will still be effective. This function requires a Linux Kernel with version at least 2.6.21.

So if you don't hit the "16 groups" limit, you may try to disable this option on your server.

0

My issue was that on the NFS server I did NOT have the group ("www-data") but the files were showing as user:www-data. So I created the group, with same ID as the client, reissued a

chown -R user:www-data

and the problem went away.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .