When NFSv3 comes into ONTAP, it sends its numeric ID. In UNIX security style volumes, this doesn't present any problem - we just just the numeric ID to determine permissions.
In your case, you sound like you have NTFS security style volumes. When the numeric ID comes into ONTAP, ONTAP tries to translate the numeric ID (say, 1234) into a UNIX user name. This is because NTFS permissions have Windows usernames associated with them and ONTAP needs a UNIX user name to start the name mapping process to determine proper access.
Because this works when you add "Everyone" to the NTFS ACL, that means the user attempting access to the mount is mapping as a user that doesn't have Windows permissions to the volume.
TR-4887 covers some troubleshooting steps for multiprotocol, but I'd suggest the following:
- check the event log after a failed access attempt - these are usually secd messages (event log show -messagename secd in the CLI)
- check the UNIX user's credentials using:
::> set advanced
::*> access-check authentication show-creds -node node1 -vserver SVMname -uid 1234 -list-name true -list-id true
From your NFS troubleshooting output, I see a few potential issues:
- Your sectrace is failing at "/" - that's the SVM root volume. That likely is preventing traverse access to the volumes below it. That path has to allow at least read access to clients and users, so that's why adding "Everyone" with READ allows access. TR-4067 covers the vsroot volume access requirements starting on page 21 and also on page 75: https://www.netapp.com/pdf.html?item=/media/10720-tr-4067.pdf
With NTFS permissions, you can allow just "traverse" rights to Everyone to allow access.
- LDAP client is set to AD-IDMU; this isn't a schema Windows uses in modern AD servers. Try MS-AD-BIS instead
- if getxxbyyy is failing to look the user ID up, then LDAP is *not* working; "ldap check" simply means 1) we can connect to the LDAP server 2) we can bind to the server 3) the base DN you specified exists on the server. We don't look any users or groups up on that command.
- the UID that you are trying looks a lot like the SSSD generated UID (SSSD uses the Windows SID and converts it to a UID) rather than one that lives in the LDAP server in the uid/uidNumber attributes on the user object. ONTAP doesn't support that method; the ID has to actually exist on the LDAP server you specified. TR-4835 has more details about LDAP and ONTAP. https://www.netapp.com/us/media/tr-4835.pdf
