topic Re: Multiprotocol Access Troubleshooting in ONTAP Discussions

Multiprotocol Access Troubleshooting

Oneplus7 — Wed, 04 Jun 2025 10:07:39 GMT

We have configured a volume on a dedicated SVM and are making this accessible via CIFS and NFS.

The CIFS access is working as we'd expect but we are having issues with the NFS access from a RedHat Enterprise Linux server (RHEL 7.9)

Users are logging into the RHEL server using Active Directory credentials and can successfully mount / access the files in the volume but ONLY when we add EVERYONE to the ACL.

When we try and create a file from the Linux server (using touch) we get "Permission denied"

We have configured LDAP on the SVM and believe it to be functional but name resolution does not seem to be working correctly.

AD Forest Functional Level and Domain Func Level are 2016
Clustered OnTAP version is 9.9.1

Anyone able to assist with best steps to troubleshoot this?

I will attach a file showing steps taken so far and relevant output / configuration

Re: Multiprotocol Access Troubleshooting

parisi — Wed, 15 Dec 2021 14:25:03 GMT

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

Re: Multiprotocol Access Troubleshooting

Oneplus7 — Thu, 16 Dec 2021 15:34:07 GMT

Thank you very much for the detailed response and information. It will take me a day or so to work through everything you've provided but I wanted to acknowledge the time you have taken to respond, which is appreciated.

I will update again once I have made progress.

Re: Multiprotocol Access Troubleshooting

tahmad — Tue, 28 Dec 2021 07:47:50 GMT

where you able to test the action plan provided by Parisi? @Oneplus7