I'm not sure what PROXY_V4 does with ACLs, though it seems like it should support
them. If so, it supports NFSv4 ACLs. The proxied server would have to offer NFSv4 ACLs. If
the proxied server is Linux, it will translate POSIX ACLs to NFSv4 ACLs. If the proxied
server is Ganesha, it would do the same for FSALs that support POSIX ACLs (not FSAL_VFS
yet).
The call to fsal_check_access_no_acl() in the log indicates Ganesha is doing mode bit
permission checking. The log indicates the permissions are 0770, so the other permissions
are being used. That strongly suggests idmapping is failing somewhere, check out the
various things I pointed to in the previous e-mail.
Frank
-----Original Message-----
From: Nehring, Shane R [LAS] [mailto:snehring@iastate.edu]
Sent: Tuesday, June 21, 2022 12:41 PM
To: ffilzlnx(a)mindspring.com; support(a)lists.nfs-ganesha.org
Subject: Re: [NFS-Ganesha-Support] Re: Proxy-v4 access denied
Thank you Frank, the additional acl debug logging might've given me a direction
to go:
[svc_7] nfs_access_op :NFS4 ACL :DEBUG :Requested
ACCESS=READ,LOOKUP,MODIFY,EXTEND,DELETE,-
[svc_7] nfs_access_op :NFS4 ACL :DEBUG :access_mask = mode(rwx)
ACL(list_dir,add_file,execute,add_subdirectory,delete_child)
[svc_7] fsal_check_access_no_acl :NFS4 ACL :F_DBG :file Mode=0770, file
uid=0, file gid= 0, user uid=423245, user gid= 101,
access_type=0X7000000
[svc_7] fsal_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X0, Access
Type=0X7000000 Allowed=0X0 Denied=0X7000000 DENIED [svc_7]
nfs_access_op :NFS4 ACL :DEBUG :Supported
ACCESS=READ,LOOKUP,MODIFY,EXTEND,DELETE,-
[svc_7] nfs_access_op :NFS4 ACL :DEBUG :Granted ACCESS=-,-,-,-,-,-
Does ganesha interpret posix acls for the purpose of determining access? I've
got these trees setup with perms delegated primarily with posix acls on the
underlying filesystem instead of traditional owner/group perms.
In the meantime I'll look at the captures and getting them filtered and
investigate id mapping.
Shane
On Tue, 2022-06-21 at 11:53 -0700, Frank Filz wrote:
> You config looks like it should work, however, do you gave ID Mapper
> configured identical on all three hosts involved (client, Ganesha
> server, proxied server)? Could you share you network traces (both between
client and Ganesha and between Ganesha and the proxied server)? Could you
share the debug log? You could add NFS4_ACL to log the permission checking
which might help.
>
> On the idmapper stuff, you need to determine if the owner/group
> attributes coming from the server are in the form "user@domain" or
> "1234". You may need to set NFS4 { Allow_Numeric_Owners = true; } in
> your config if the owner/group attributes are numeric. The parameter
> Only_Numeric_Owners will cause Ganesha to issue owners in the form "1234"
instead of "user@domain" for client side GETATTR and proxy side SETATTR (and
OPEN/CREATE). There are kernel NFS parameters that control this also for client
and I believe the server.
>
> I'm going to bet that idmapping issues are the cause here. I hope the
> above gives you enough to go on to fix the issue if that's the case.
>
> Frank
>
>