Name mapping always comes into play when coming into an NTFS security style volume from NFS. The reason is that the UNIX user isn't a part of the NTFS ACLs, so ONTAP needs to find a valid Windows user to map to and then check the ACLs for that user.
secd name mapping show doesn't actually check the actual name mapping; instead, it just tells you what we'd be mapping to by default, and if there are name mapping rules, what we'd map if those were in play.
A better command to use is "authentication show-creds," which gives:
- name mappings
- group memberships in UNIX and Windows
- UID/GID/SID information
TR-4835 has a list of commands to help troubleshoot this.
What is likely happening here is that the user coming in from the Linux box isn't being translated properly by ONTAP to a user name, so we can't map to a valid Windows user. "event log show" will give you messages to clue you in to what might be happening here.
Also a possibility is that this client is using SSSD to generate UID/GID numbers dynamically via the Windows AD SID, which ONTAP doesn't support. You'd either need to populate the AD LDAP UNIX attributes with static entries and configure ONTAP to query those or add local UNIX users and groups that match those numeric IDs. You can test that theory by:
- running "id username" on the Linux client to get the UID/GID info
- creating a local UNIX user and group with those attributes (unix-user create/unix-group create)
- running the "authentication show-creds" command to verify the user is mapping and resolving properly from Windows to UNIX and back again
- testing your mount
An alternate way of doing this is using NFSv4.x and disabling numeric ID support, which forces a domain name string to come from the client, which won't require numeric ID to name resolution.