NFS permission problems - group access not working

[alexander.isacson]

Hello

I'm trying to set up NFS from my readyNas to replace a the NFS server I had before. I have created a shares for video, music etc and I have also created groups on the readynas that will belong to each share. I have also synced the UIDs and GIDs so that they are the same on the NAS and the clients.

From the NAS

Code: Select all

nas:/c# id alexander
uid=2000(alexander) gid=2000(alexander) groups=2000(alexander),100(users),3002(documents),3001(music),3005(pictures),3003(games),3004(videos)

nas:/c# cat /etc/exports
"/documents" *(insecure,insecure_locks,rw,async)
"/downloads" *(insecure,insecure_locks,rw,async)
"/games" *(insecure,insecure_locks,rw,async)
"/music" *(insecure,insecure_locks,rw,async)
"/pictures" *(insecure,insecure_locks,rw,async)
"/videos" *(insecure,insecure_locks,rw,async)
"/homes" *(insecure,insecure_locks,rw,sync)


From a client

Code: Select all

alexander@client:/mnt$ id
uid=2000(alexander) gid=2000(alexander) groups=4(adm),20(dialout),21(fax),24(cdrom),26(tape),29(audio),30(dip),44(video),46(plugdev),60(games),104(fuse),106(lpadmin),112(netdev),121(admin),122(sambashare),2000(alexander),3001(music),3002(documents),3003(game),3004(videos),3005(pictures)

alexander@client:/mnt$ cat /etc/fstab
<SNIP>
192.168.0.6:/documents        /mnt/documents  nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/downloads        /mnt/downloads  nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/videos           /mnt/videos     nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/music            /mnt/music      nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/pictures         /mnt/pictures   nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/games            /mnt/games      nfs rw,user,noauto,hard,intr    0       0
192.168.0.6:/backup           /mnt/backup     nfs rw,user,noauto,hard,intr    0       0


After much fiddling I was able to get the user to mount the directory. (The problem was that the user did not have read and execute rights on the directory on the client to which the share should be mounted.) However I get permission denied as soon as I try to cd into a directory.

Code: Select all

alexander@client:/mnt$ ls -lhd pictures/
drwxrwx--- 13 pictures pictures 16K 2010-04-05 11:32 pictures/
alexander@client:/mnt$ ls -lhdn pictures/
drwxrwx--- 13 3005 3005 16K 2010-04-05 11:32 pictures/
alexander@client:/mnt$ cd pictures/
bash: cd: pictures/: Permission denied

Why do I get permission denied? Obviously the user belongs to the correct group. If I ssh to the readynas as the user alexander I can cd into the directory without any problems. Where do I start looking at the error? Is it the client or the server that doesn't allow the access? If a use the world readable/writable folder I can access it and its contaning files without any problems.

Thanks
/Alexander

[alexander.isacson]

What am I overlooking?

It works if I make the shared files world readable or if I browse them as root. But I don't want to make the NFS shares world readable. Why aren't the group permissions honored?

If I ssh to the NAS as the user alexander I can access the directories based on the group permissions locally on the NAS. But if I try to do it over NFS it gives me permission denied.

If I change the ownership of a directory so it is owned by "alexander" I can access it over NFS.

[ewok]

Can you try temporarily setting the group owner on the pictures share directory to 20 and see if that helps?

[alexander.isacson]

Thanks for the suggestion!

I did as you said and ran the following on the NAS

Code: Select all

chgrp 20 pictures

I remounted the pictures share on the client. It showed up as beloning to the group dailout. Now I had access to the directory!

Why does it work with the dailout group and not with the group I created for this porpose? Are the gid to high?

[ewok]

The underlying authentication mechanism only supports 16 groups. Look here for more info:

http://nfsworld.blogspot.com/2005/03/wh ... ation.html

[alexander.isacson]

Thanks - now I know where to start looking for a solution. I found this switch in the mountd manpage:

-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 authentica‐
tion) 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 I added the file /etc/default/nfs-kernel-server with the following line in it

Code: Select all

RPCMOUNTDOPTS="--manage-gids"

Unfortunately the ReadyNAS is running kenel:

Linux sigma 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown

What have other people done to get around the problem? What I'm thinking right now is to set the GIDs on NAS-relevant groups below 30 so they come first in the list.

[alexander.isacson]

If anyone else reads this I changed all the GIDs to a low number and now everything works. However I wish that netgear would upgrade the kernel to 2.6.21 so that you can use the RPCMOUNTDOPTS="--manage-gids" option.

[lith]

Old thread, but this is still an issue - the kernel on newer versions is now able to support the --manage-gids option, which is working fine
Not sure when this was from, I'm running 4.2.19 which is at 2.6.37 (x86)