What you likely saw was this:
When you have auth-sys-extended-groups enabled with ID numerics, ONTAP will attempt to map the numeric ID to a name to resolve groups. If that numeric doesn’t exist, you get the error you saw.
I wrote up a section in the new TR-4067 update that is currently being reviewed.
See below:
NFSv3 using AUTH_SYS sends numeric ID information for users and groups to perform user authentication to NFS mounts for permission resolution.
NFSv4.x with ONTAP has a feature that allows NFSv4.x mounts to leverage numeric ID strings instead of name strings, which allows NFSv4.x operations without needing centralized name services, matching names/numeric IDs on client/server,
matching ID domains, etc. (-v4-numeric-ids)
Enabling the -auth-sys-extended-groups option will cause numeric ID authentication to fail if the UNIX user numeric ID can’t be translated into a valid UNIX user name in name services. This will counteract
the -v4-numeric-ids option, as ONTAP will need to query the incoming numeric user ID to search for any auxiliary groups for authentication. If the incoming numeric ID cannot be resolved to a valid UNIX user or the client’s
UNIX numeric UID is different than the numeric UID ONTAP knows about, then the lookup will fail with
secd.authsys.lookup.failed in the event log and ONTAP will respond to the client with the AUTH_ERROR “client must begin a new session,” which will appear as “Permission denied.”
To use both options, use the following guidance:
·
If you require users and groups that either can not be queried from both NFS client and server or have mismatched numeric IDs, you can leverage NFS Kerberos and NFSv4.x ACLs to provide proper authentication with NFSv4.x, as clients
will send name strings instead of numeric IDs.
·
If you are using -auth-sys-extended-groups with AUTH_SYS and without NFSv4.x ACLs, any user that requires access via NFS will require a valid UNIX user in the name service database specified in
ns-switch (can also be a local user).
From: Toasters <toasters-bounces@www.teaparty.net>
On Behalf Of Scott Classen
Sent: Friday, June 5, 2020 5:30 PM
To: tmac <tmacmd@gmail.com>
Cc: Toasters <toasters@teaparty.net>
Subject: Re: nfs4_setfacl - Failed setxattr operation: Invalid argument
|
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless
you recognize the sender and know the content is safe. |
Yes, both
sibyls2::*> nfs show -vserver als-enable-ds1 -fields v4.0-acl,v4.1-acl
vserver v4.0-acl v4.1-acl
-------------- -------- --------
als-enable-ds1 enabled enabled
Turns out that I had added an ACL while messing around with NFSv4.0 and it was preventing v4.1 ACLs from working:
sibyls2::*> file-directory show -vserver als-enable-ds1 -path /BL831/ISPYB/
(vserver security file-directory show)
Vserver: als-enable-ds1
File Path: /BL831/ISPYB/
File Inode Number: 64
Security Style: unix
Effective Style: unix
DOS Attributes: 10
DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
UNIX User Id: 0
UNIX Group Id: 0
UNIX Mode Bits: 755
UNIX Mode Bits in Text: rwxr-xr-x
ACLs: NFSV4 Security Descriptor
Control:0x8014
DACL - ACEs
ALLOW-S-1-8-1000-0x1601ff-DI
ALLOW-OWNER@-0x1601ff
ALLOW-GROUP@-0x1200a9-IG
ALLOW-EVERYONE@-0x1200a9
Vserver: als-enable-ds1 (internal ID: 4)
Error: Lookup CIFS/NFSV4 account SID and translate to corresponding unix name procedure failed
[ 0 ms] Unix User ID found in Name Service Negative Cache
**[ 0] FAILURE: Unable to retrieve UNIX username for UID 1000
[ 0] Could not translate NFSv4 SID 'S-1-8-1000'
[ 0] Could not find Windows SID 'S-1-8-1000'
[ 0] SID lookup failed
I wasn’t sure how to clear this ACL from the filer command line so I just deleted the volume, created a new vol, and now nfs4_getfacl and setfacl are working as expected.
Thanks to Scott Gelb for the insight to use the "file-directory" show
command.
Scott