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@mydomain.fqdn: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