Created attachment 1343317 [details] Bug report info we have a common working directory dri_fleat in the gluster volume drwxrwsr-x 22 root dri_fleat 4.0K May 1 15:14 dri_fleat my user (phaley) does not own that directory but is a member of the group dri_fleat and should have write permissions. When I go to the nfs-mounted version and try to use the touch command I get the following ibfdr-compute-0-4(dri_fleat)% touch dum touch: cannot touch `dum': Permission denied One of the sub-directories under dri_fleat is "test" which phaley owns drwxrwsr-x 2 phaley dri_fleat 4.0K May 1 15:16 test Under this directory (mounted via nfs) user phaley can write ibfdr-compute-0-4(test)% touch dum ibfdr-compute-0-4(test)% I have put the packet captures in http://mseas.mit.edu/download/phaley/GlusterUsers/TestNFSmount/
Created attachment 1343318 [details] gluster state dump
Hi Steve, could you pass along a little more details? 1. exact version of Gluster $ rpm -q glusterfs 2. count and numbers of the groups the user belongs to on the nfs-client $ id 3. count and numbers of the groups the user belongs to on a Gluster server $ id You may also find a few more details about workarounds for environments where a user is part of many groups at http://docs.gluster.org/en/latest/Administrator%20Guide/Handling-of-users-with-many-groups/
Also, the tcpdumps contain NFSv4 traffic. Gluster/NFS only supports NFSv3, so we need to know if you are using NFS-Ganesha or something else. Thanks!
Created attachment 1344642 [details] access call that results in a failure Gathered with: $ tshark -r capture_nfsfail.pcap -V frame.number==21651 This shows that the RPC credentials have a list of groups for the user with exactly 16 groups. This is the maximum of groups that the NFS protocol with AUTH_UNIX supports, the list may be trimmed. If the client does not pass the group-owner of the directory, the NFS-server will reply with "permission denied".
Niels, we had 2 students (one a member of 8 groups, the other a member of 5 groups) each create a directory under /gdata/projects/nsf_alpha/Test (gluster mount). Then they went to /mnt/mseas-data2_nfs/projects/nsf_alpha/Test/ Neither was able to create a directory under a directory that they did NOT own (although group write was on and both were members of the relevant group) Both were able to create a directory under a directory that they DID own That's the same behavior we saw earlier. Thanks!
Niels, is there any other info I could give you on this? Thanks, Steve
Jiffin or Kaleb, can you have a look at this one?
The bug was opened in downstream by mistake I guess. I am reopening the bug in upstream for the time being.
This bug is moved to https://github.com/gluster/glusterfs/issues/929, and will be tracked there from now on. Visit GitHub issues URL for further details