Ask The Experts

Mixed Protocol access - Files written from CIFS show as nobody:nobody on NFS

We're trying to setup our Netapp with Mixed Protocol access for NFS and CIFS.
When we write a file from Windows, the files show as nobody:nobody on the Linux NFSv4 mount. We want to map usernames and groups between CIFS and NFS, so files written show the same user and group. 
-rwxrwxrwx  1 nobody          nobody                0 Aug 30 12:59 file01.txt
We've configured ldap on our Netapp to handle the Windows to Unix username resolution. Our ns-switch is configured for ldap then files. 
Usernames are 1:1 mapping between Windows and Unix. We have not setup any name mapping on the Netapp. 
When we show the effective permissions for an Active Directory test account, we can see it maps to 'pcuser' in Unix. We'd expect the Unix User name to be testuser01.
netapp01::> vserver security file-directory show-effective-permissions -vserver testvserver01 -win-user-name testuser01 -path / -share-name testshare01

    Windows User Name: testuser01
       Unix User Name: pcuser
            File Path: /
      CIFS Share Path: /testshare01
When we write a file to the same share from Linux NFS, we can see the correct username and group for the files. 
-rw-r-----  1 testuser01 testgroup01       0 Aug 31 06:35 file02
Files written from NFS also show in the file properties on Windows. 
We are using SSSD with ID Mapping on the Linux client, we have tested by disabling SSSD ID Mapping and adding the UID and GID to unix attributes for the testuser01 account in Active Directory User Properties. We still have the same issue. 
Our security style is set to 'unix' on our Netapp. 
We're using a 'simple' bind account for our ldap connection and are confident the netapp can communicate to AD for Windows Username resolution. 
This is an issue writing files from Windows and showing the correct username and group on Linux NFSv4 mounts. I have tested with NFSv3 and get the same issue. 
We are running NetApp Release 9.5P4. 
We've tried disconnecting the CIFS drive mapping, restarting CIFS, mapping the CIFS share and remounting NFS. But as we're unable to map win-unix names on the Netapp.
Any help here would be appreciated. 



The problem is with the windows-unix name mapping. It seems to be failing based on your explanation.


If it fails then the Windows users will get mapped to default UNIX user PCUSER. This will result in windows user mapping to ID 65534 which is nobody/nfsnobody user in LINUX.  So files created by this windows user, when seen from a NFSv3/v4 client would show owner as 65534(nobody/nfsnobody). 

For this to work properly the name-mapping has to be configured either on LDAP or Local FILES( using vserver name-mapping).

In My Lab:
cdot-vsim2::> set d -c off ; row 0
cdot-vsim2::*> diag secd authentication show-creds -node cdot-vsim2-01 -vserver vijay_9_3 -win-name naslab\vijay <<< Windows user naslab\vijay gets mapped to unix user root( because of CIFS option "-is-admin-users-mapped-to-root-enabled" is set to true and Vijay is a part of administrators group)
UNIX UID: root <> Windows User: NASLAB\vijay (Windows Domain User)
GID: daemon
Supplementary GIDs:

cdot-vsim2::*> diag secd authentication show-creds -node cdot-vsim2-01 -vserver vijay_9_3 -win-name naslab\pran <<< Windows user naslab\pran gets mapped to unix user user1( explicit mapping defined)
UNIX UID: user1 <> Windows User: NASLAB\pran (Windows Domain User)
GID: user1
Supplementary GIDs:

cdot-vsim2::*> diag secd authentication show-creds -node cdot-vsim2-01 -vserver vijay_9_3 -win-name naslab\test2 <<<<<<< Windows user naslab\test2 gets mapped to unix user pcuser( default mapping used)
UNIX UID: pcuser <> Windows User: NASLAB\test2 (Windows Domain User)
GID: pcuser
Supplementary GIDs:


cdot-vsim2::*> vserver name-mapping show -vserver vijay_9_3 -direction win-unix
Vserver: vijay_9_3
Direction: win-unix
Position Hostname IP Address/Mask
-------- ---------------- ----------------
1 - - Pattern: naslab\\administrator
Replacement: root
2 - - Pattern: naslab\\pran
Replacement: user1
2 entries were displayed.


I would suggest to recheck the LDAP name-mapping and check why it is not working.
You can also create a name-mapping locally on the SVM like i did and check if it works.

NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner