Hi Marcus, thanks for your reply. I'll provide some more details belog Question 3: ================== This is the complete *working* ACL: --------------- myuser@myhost:/nfsv4/share/> nfs4_getfacl repodir A:fdg:MYGROUP@xxxxxxxxxxxxx:rwaDxtTnNcCoy A:fd:OWNER@:rwaDdxtTnNcCoy A::EVERYONE@:rxtncy D::OWNER@: D::EVERYONE@:waDTC --------------- This is the complete non-working ACL: --------------- myuser@myhost:/nfsv4/share/> nfs4_getfacl repodir A:fdg:GROUP@:rwaDxtTnNcCoy A:fd:OWNER@:rwaDdxtTnNcCoy A::EVERYONE@:rxtncy D::OWNER@: D::EVERYONE@:waDTC ---------------> what is the fileserver running? netapp? solaris? linux nfsd?? something else?
Server: NetApp FAS 3140 mit ONTAP 8.1.4P1 7-mode> Presumably your client is linux - what version? If from a distribution which distro & package version?
Client: openSUSE 13.2, 3.16.7-7-desktop, nfs-client = 1.3.0> Are you using gssapi? (better for tracing purposes if you can do this without.)
We are using GSSAPI/Kerberos protected NFSv4 shares mounted like to:nfsv4_server.fqdn:/vol/myshare on /nfsv4/share type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,local_lock=none)
We have the user "myuser" a member of "mygroup" but not his primary group, i.e.
# id myuser uid=xxx(myuser) ... groups=xxx(mygroup) ... > You speak of "domains" - what sort are these and why do you think > they be considered the same as "@GROUP"? > We have the following ID mapping on the Linux clients: # cat /etc/idmapd.conf --------------- [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = mydomain.fqdn [Mapping] Nobody-User = nobody Nobody-Group = nobody ---------------Note that in general, all POSIX ACLS based on user groups are working perfectly fine. So ID-mapping seems to be OK in general.
> Client & server identities and groups might map differently - is this the case here?
I have no idea about the server side...
Can you demonstrate your problem happen with dd or cp? Or does it only happen with git?
Nope, only git so far. > Can you record a network trace of the bad thing happening? (this will > point whether it's a client or server side problem.) Please find a wireshark trace of the failed "git push" command here: http://wikisend.com/download/940986/wireshark_git.pcapng (7 days availability) where the problem seems to be ---------------148 0.070260000 192.168.109.118 10.162.229.2 NFS 438 V4 Call (Reply In 149) WRITE StateID: 0xcded Offset: 0 Len: 156 149 0.071190000 10.162.229.2 192.168.109.118 NFS 162 V4 Reply (Call In 148) WRITE Status: NFS4ERR_ACCESS
--------------- me = 192.168.109.118 nfs4_server = 10.162.229.2 Not much more that I can see here unfortunately...
Possibly helpful to know,: unix mode permissions work differently than an acl, with unix modes, owner permissions eclipse group permissions. with acls, group permissions add to owner permissions. To accurately map unix mode bits into nfsv4 acls, you have to also include 'deny' entries to keep groups from adding permissions the user doen't have.
Thanks for the hints and for your help! I'll do some more thinking about the problem :) JB
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
