FAS and Data ONTAP Articles and Resources

cDOT Multiprotocol Usermapping




I took my very old Usermapping presentation which is floating around for 10+ years and modified it to apply for Cluster-Mode. It is not perfect yet, but a good start to understand how usermapping works and how to configure it.





2014.03.19: new version. enhanced some slides and added two "scratch" slides with details and options to change system behaviour.

Please Note:

All content posted on the NetApp Community is publicly searchable and viewable. Participation in the NetApp Community is voluntary.

In accordance with our Code of Conduct and Community Terms of Use, DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information (PII)
  • Copyrighted materials without the permission of the copyright owner

Continued non-compliance may result in NetApp Community account restrictions or termination.


great document..

i'm trying to do "NFS client accessing file with NTFS PermSet" by only setting  nfs -default-win-user...

has anyone got this to work?

from unix, it keeps saying permission denied users.. it only works in unix when the user is 'root'.

diag secd name-mapping show -node XX -vserver YY -direction unix-win ZZ... does show the mapping as the default-win-user correctly... it is as if it ignores the default mapping and just goes to access denied


This might be a stupid question, but does the default win user you are mapping to the permissions to access the file?


definitely has access cos we are able to map a drive to the share using the specified 'default win user' and it is able to create files etc..


I got a bit out of pratice, but let's try it:

First you have to check the UID of the NFS user you are getting a permission denied. Use the "id" command at your NFS client to find out the UID of this user.

Then check, if cDOT can translate this UID into a username:

set diag;

*> secd authentication translate -node <nodename> -vserver <vservername> -uid <id>

This should tell you the username. If this throws a error, you need to fix the name service (create corresponding local users (a /etc/passwd equivalent) with "vserver services unix-usee create" or connect to NIS or LDAP.

If this lookup is successfull, ONTAP will translate this username through the mapping table "vserver name-mapping show". Most likely you didn't change anything here and that is okay. ONTAP will then send this name to AD. If it cannot find the username, it will use the default windows user.

I assume step 1 breaks in your environment, meaning you have no name service configured which is able to translate a UID into a username.


I ran:

secd authentication translate -node <nodename> -vserver <vservername> -uid <id>

and it came back with:

Error: command failed: Failed to resolve UNIX ID from user name. Reason: "SecD Error: user not found".

hence I would expect it to fall back to default-win-user

when I run:

diag secd name-mapping show -node <nodename> -vserver <vservername> -direction unix-win <unix username>

it will correctly return the default-win-user (which has access)

Do i still need to 'fix the name service'? or as I understand "if it cannot find the username, it will use the default windows user"?

strange thing i find is that the name-mapping is returning the default-win-user but we get permission denied in unix

fyi.. there is a good reference on troubleshooting cdot multiprotocol here: http://wiki.krogloth.de/wiki/NetApp_cDOT/Multiprotocol


I don't know of a way to achieve this (doesn't mean there exist one).

ONTAP needs to be able to map the incoming UID to a username. Then this one can be mapped to a default windows user. If ONTAP cannot get the username, it throws permission denied. You should be able to see the unsuccesfull lookup using

event log show -source secd


thanks! creating a local unix user in the vserver to allow it to convert UID to username worked for NFSv3. "root" obviously worked cos UID 0 was defined on the local vserver. NFSv4 didn't give a permission denied and we were able to do a 'ls'.. but we had some other issues which we have yet to investigate..  just mounting the volume as a cifs mount seems to be the simplest solution and this change should be transparent to the users.


7-Mode always performs user mapping, even when doing CIFS to NTFS qtree access. What about C-Mode? In there any user mapping performed in this case? In 7-Mode it was common source of problems.


IIRC 7mode did this only, if both NFS and CIFS license was installed and/or both protocols were enabled on the system.

Anyways, AFAIK cDOT works the same. If you enable both protocols in a VSM, usermapping is done all the time.

There is a good reason for that: If you switch security style, you want the permissions of every file pre-populated with the correct permissions. Therefore ONTAP always write both permission sets. Otherwise you would have to "re-ACL" every object in the file system when switching security style, or live with insecure defaults.


Excellent summary presentation.  Thanks for updating it.

All Community Forums