topic Re: Access NTFS qtree via NFS and usermapping problem in Network and Storage Protocols

Access NTFS qtree via NFS and usermapping problem

USER_2000 — Thu, 05 Jun 2025 05:32:09 GMT

Here is what I want to do:

I have a FAS2240 with NetApp Release 8.1.3 7-Mode.

I have a CIFS qtree and I want to access it with NFS. So I started NFS on the NetApp and created /etc/exportfs like this:

/vol/vol1/qtree_vol1 -sec=sys,rw

I can mount the filesystem from my Solaris box with NFSv4 without problems. I have set the NFSv4 domain on the NetApp

mount -o vers=4 netapp:/vol/vol1/qtree_vol1 /mnt

But when I try to access the share from Solaris, I get a permission denied as root as well as with a non-root user. The user has full rights on the exported folder in NTFS. On the Solaris box all users have the same username as they have in Active Directory. I thought, this would suffice to not have to use /etc/usermap.cfg and /etc/passwd on the Netapp. But obviously, the Solaris user does not get mapped to the Active Directory user. Can this be done? How?

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 10:57:13 GMT

NetApp must be able to a) map Unix user name to Unix user UID and b) map Unix user name to Windows user name. You said nothing about configuring user mapping, so I assume nothing is configured ☺

In practice that means that NetApp and Unix must use the same user database backend, most likely LDAP. And to ensure that Unix user means the same as Windows user, this LDAP backend usually must be AD.

Please see tr3490 for details on multiprotocol access and tr3458 for example of using AD as common backend.

Re: Access NTFS qtree via NFS and usermapping problem

USER_2000 — Tue, 22 Jul 2014 12:02:45 GMT

You are probably right, but I wonder whether it is really necessary to use a common backend, which I do not have. (You gave me a lot to read and I admit I have not read everything yet)

In tr3580 it says:

"NFSv4 does not use UID/GID as the initial method of interaction between the client and the server by default. Instead there is string-based authentication between the client and the server."

And since the qtree is NTFS Style, it should not need any UID/GID from Unix, since they are not used anyway?

With the user name string from NFS the NetApp should be able to look up the user in AD directly?

Do you know why step a) is necessary and how step b) is done?

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 12:31:25 GMT

UIDs/GIDs are still required at RPC level, which does not change with NFS v4. It could be that using NFS v4 with Kerberos bypasses this, but I do not have practical experience. IIRC your example explicitly used auth=sys which does need to know numerical IDs. Also NFS v4+ still allows pure numerical IDs as fallback, so storage still must be prepared to resolve them. Also for security style unix Data ONTAP stores numerical IDs internally and again must be able to resolve them. I doubt it has two different code paths.

User mapping rules are configured in /etc/usermap.cfg; you mentioned this file yourself.

It is possible to do without common backend; it is just that for any practical purposes it becomes unmanageable very fast unless you need to grant access to fixed number of users that change infrequently.

Re: Access NTFS qtree via NFS and usermapping problem

USER_2000 — Tue, 22 Jul 2014 12:47:44 GMT

Most of my users are Windows users. That´s why I decided to use NTFS style on the qtrees. I have about 10 Unix hosts with less than 20 users. I have added my credentials to the passwd file on the NetApp and I can access the exported filesystem now. I think, for this small number of users it should be possible to use this approach. I don´t need a usermap.cfg file, since the NetApp automatically checks AD for my Unix user name, which is the same user name in AD. Thank you for pointing me to tr3490, which explains the mapping very detailed. Things are much clearer now.

It would be nice, if there would be an option to turn of usage of UID/GID, since its really not necessary in my environment and makes things just more complicated. May be one day it will be added?

Thank you for your help.

Re: Access NTFS qtree via NFS and usermapping problem

VENKATA04 — Tue, 22 Jul 2014 13:50:22 GMT

I take it you are trying to map a UNIX user to Windows user but you get access denied message.

have you pasted full passd line in to \\filer\etc\passwd ?

I was once caughtup by passd line , I missed semi colon from passd line!

If you are still having issues please paste output of wcc -u username

then try

options cifs.trace_dc_connection on

options cifs.trace_login on

After enabling above options, from the solaris client try accessing the nfs export in question as non-root user (su - user2000), on the filer check for any authentication or mapping errors in /etc/messages.

you could also enable cifs auditing

cifs.audit.enable

cifs.audit.nfs.enable

cifs.audit.nfs.filter.filename

cifs.audit.saveas

Hope this helps.

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 14:11:32 GMT

NFSv4 uses string based by default for security purposes, such as username@nfsv4.domain. This can be bypassed from the storage via the nfs.v4.id.allow_numerics option.

That said, aborzenkov is correct - you need to be able to map UNIX users to Windows users when using NTFS style volumes.

The reason is this - NTFS style volumes will use NTFS style ACLs. The storage must be able to discern the user identity to properly grant or deny access to the requesting user.

If you are trying to access using "root" then one of four things must happen:

1) A user mapping rule must map root to a valid Windows user (ie DOMAIN\user <= root)

2) A user named "root" must exist in the AD domain to allow implicit 1:1 mapping

3) The option wafl.nt_admin_priv_map_to_root must be set

4) The option wafl.default_nt_user must be set

The most secure of the above would be #1 or 2.

It looks like you worked around the issue by adding users to the passwd file, so that's good. But there is, and will not be, a way to bypass UID/GID. It's a security hole. You don't want to allow anyone access to your data without needing a valid user.

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 14:59:28 GMT

But there is, and will not be, a way to bypass UID/GID. It's a security hole. You don't want to allow anyone access to your data without needing a valid user.

I think what confuses OP here is that we both speak about UIDs. OP is right in that strictly speaking UID are not needed in described scenario. What really happens here is user validation on server side. NetApp gets client user name in NFSv4 request and it must verify that user with this name actually exists from server point of view. So it must perform Unix user name lookup first. That this lookup returns UID as side effect is irrelevant in this context. This validation likely happens even before NetApp tries to access file (and knows its security style).

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 15:00:43 GMT

Thank you for your help.

It would be prudent to mark question as answered then (or at least answers as helpful )

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 15:03:14 GMT

If we're talking NFSv4 and bypassing the user string, then the aforementioned nfs.v4.id.allow_numerics set to "on" would achieve more NFSv3-like behavior.

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 15:09:30 GMT

If we're talking NFSv4 and bypassing the user string,

No, we are talking about using user string in NFSv4 but bypassing Unix user lookup on NetApp side.

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 15:14:47 GMT

User lookup will happen for all NFS versions, regardless of options if the volume is NTFS security style. There is not any way to get around that, as there needs to be a way to discern the NTFS ACL for the user requesting access.

If the volume is UNIX security style, then there would be no need to look up a user name for NFSv4 (or map it to a Windows user) as long as the nfs.v4.id.allow_numerics is enabled. Instead, the UID/GID would be passed.

Windows access will always map to a UNIX user, however, no matter what security style is being used.

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 16:21:16 GMT

Now I became curious myself To discern NTFS ACL you need to know Windows user name (OK, you need Windows SID, but let's keep it simple); to get Windows user name you need to know Unix user name and with NFSv4 you get user Unix name from client already. So what is technical reason to perform user lookup at this point?

Re: Access NTFS qtree via NFS and usermapping problem

USER_2000 — Tue, 22 Jul 2014 17:27:31 GMT

That's exactly what I mean. In my opinion, it is a security hole, no matter whether UIDs or names are used. It can be exploited easily, so why bother about UIDs? It does not add any extra security or am I missing something? Of course I will restrict access to the exported qtree to hosts I know. As long as users on these hosts have no root access to their host, its fairly safe. UIDs lookup would not make any difference, right?

Re: Access NTFS qtree via NFS and usermapping problem

USER_2000 — Tue, 22 Jul 2014 17:32:35 GMT

I wasn't aware of the logging options. I will certainly have a look into that. Thank you.

Yes, as stated before I have added the users to /etc/passwd and access is fine now.

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 17:51:51 GMT

The client may know the user name, but the storage does not. It needs to look up the Windows user name based on the UNIX name/UID it receives from the client when the volume is NTFS security style. This is true for NFSv3 and NFSv4.

When a NFSv4 request comes in to storage, the client knows the user as username@nfsv4id.domain. The storage must also recognize that username@nfsv4id.domain, else the user will get squashed to "nobody" (or the equivalent set in idmapd.conf). Everything, including case, much match EXACTLY or the storage will not consider the string valid. However, the client will not send the string; it will send the numeric. Then the storage must figure the rest out.

The v4id.domain is set via the storage option nfs.v4.id.domain in 7-mode and -v4-id-domain in cDOT. On the client, the domain is set via the idmapd.conf file.

When a NFSv3 ACCESS request occurs, the client will send the following information to the storage: UID, GID, client and auxiliary GIDs.

Example:

The storage must then figure out who UID 10001 is in Windows to allow access, due to NTFS permissions. To do that, it has to translate UID 10001 from a name service. In my case, I use LDAP. I'll use cDOT to illustrate this, but the same logic applies to 7-mode.

parisi-cdot::*> diag secd authentication translate -node parisi-cdot-02 -vserver SVM -uid 10001

test

Once the storage knows that UID 10001 is UNIX user "test," then the name mapping occurs. Name mapping only occurs by name, not numeric.

parisi-cdot::*> diag secd name-mapping show -node parisi-cdot-02 -vserver SVM -direction unix-win -name test

test maps to DOMAIN\test

And creds are fetched (the above name mapping/translation are done all as a part of the credential fetching):

parisi-cdot::*> diag secd authentication show-creds -node parisi-cdot-02 -vserver SVM -uid 10001 -list-id true -list-name true

UNIX UID: 10001 (test) <> Windows User: S-1-5-21-3413584004-3312044262-250399859-1114 (DOMAIN\test (Domain User))

GID: 513 (Domain Users)

Supplementary GIDs:

10011 (ldifde-group)

Windows Membership:

S-1-5-21-3413584004-3312044262-250399859-1118 DOMAIN\testgroup (Domain group)

S-1-5-21-3413584004-3312044262-250399859-513 DOMAIN\Domain Users (Domain group)

S-1-5-32-545 BUILTIN\Users (Alias)

User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x80):

In the above, we see that the user "test" belongs to testgroup, Domain Users and Users, as well as the normal Everyone, Authenticated Users, and Network Users groups.

The volume is named "ntfs" and has the following ACLs:

parisi-cdot::*> vserver security file-directory show -vserver SVM -path /ntfs

                Vserver: SVM
              File Path: /ntfs
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           Unix User Id: 0
          Unix Group Id: 0
         Unix Mode Bits: 777
Unix Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x9504
                         Owner:BUILTIN\Administrators
                         Group:BUILTIN\Administrators
                         DACL - ACEs
                           ALLOW-DOMAIN\testgroup-0x1f01ff-OI|CI
                           ALLOW-DOMAIN\Administrator-0x1f01ff-OI|CI
                           ALLOW-Everyone-0x1200a9-OI|CI

So we know that user has access based on the ACLs.

When I mount the same volume via NFSv4, I see the same UID and GID information from the client - not the user name:

However, the storage doesn't use UID/GID for access; it uses it to discern what the user is from NTFS perspective. The difference in NFSv4 is in the ACCESS reply. The reply returns owner, group, etc as the string:

Everyone, Authenticated Users, and Network UsersEveryone, Authenticated Users, and Network UsersHowecver

If I try to use a UNIX user that does not have a Windows user counterpart, I won't even be able to cd to the mount via any version of NFS, as initial authentication on the storage fails:

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh: cd: /unix: Permission denied

parisi-cdot::*> event log show
Time                Node             Severity      Event
------------------- ---------------- ------------- ---------------------------
7/22/2014 13:20:16 parisi-cdot-02   DEBUG         secd.nfsAuth.noUnixCreds: vserver (SVM) Cannot determine UNIX identity. Error: Get user credentials procedure failed
[ 5 ms] Using a cached connection to 10.228.225.120
[    12] ID 9999 not found in UNIX authorization source LDAP
[    12] ID 9999 not found in UNIX authorization source LOCAL
[    12] Could not get credentials for ID 9999 using any NS-SWITCH authorization source
**[    12] FAILURE: Unable to retrieve credentials for UNIX user with UID 9999

If I use that same 9999 UID to access a UNIX style volume, I will gain access based on the mode bits set on the volume( i.e. 777):

[root@centos64 /]# mount sn1krb:/unix /unix
[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ ls -la / | grep unix
drwxrwxrwx. 10 root root 4096 Jul 17 11:47 unix

If I write a file via NFSv4, the user will be "nobody" since the storage doesn't know who nfs4/UID 9999 is:

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ touch nfs4_newfile
sh-4.1$ ls -la | grep nfs4_newfile
-rw-r--r--. 1 nobody root 0 Jul 22 13:29 nfs4_newfile

If I change the v4-numeric-ids option to "enabled" to allow for NFSv3-like functionality, the user shows up properly:

parisi-cdot::*> nfs server modify -vserver SVM -v4-numeric-ids enabled

[root@centos64 /]# su nfs4
sh-4.1$ cd /unix
sh-4.1$ touch nfs4_newfile_numerics
sh-4.1$ ls -la | grep numerics
-rw-r--r--. 1 nfs4 root 0 Jul 22 13:31 nfs4_newfile_numerics

In NFSv4, the user string matters on writes or when trying to translate the name/group on the file.

When I write as the 9999 user, the OPEN request comes from the client as UID 9999:

The reply from the storage is that the user is "nobody":

When I use a valid NFSv4 user, that string shows up properly:

Make sense?

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 17:58:42 GMT

Sigh. None of the attached traces made it to the post. Grr.

If needed, I can save them as images and upload.

Re: Access NTFS qtree via NFS and usermapping problem

parisi — Tue, 22 Jul 2014 18:01:06 GMT

USER_2000 wrote:

It cannot be exploited as easily in NFSv4 if the user string cannot resolve and gets squashed to nobody on the storage. If the mode bits or NFSv4 ACLs are set up properly, then access won't be allowed to users named "nobody."

If using NTFS security style, if the user cannot map to a valid Windows user, then access won't be allowed at all.

Re: Access NTFS qtree via NFS and usermapping problem

aborzenkov — Tue, 22 Jul 2014 18:37:19 GMT

In my opinion, it is a security hole, no matter whether UIDs or names are used.

Well ... traditional NFS authentication model is weak, there is nothing new. Use Kerberos if you need something more trustworthy.

It can be exploited easily, so why bother about UIDs?

Forget about UID. I apologize for causing this confusion. It is not about UID, it is about verifying that user name supplied by client actually exists.

It does not add any extra security or am I missing something?

In your specific case it prevents client from supplying user name Administrator (or any user name for that matter) and getting some more access than intended. By verifying user name NetApp can restrict access only to authorized users.

As long as users on these hosts have no root access to their host, its fairly safe.

Nothing precludes user space NFS client implementation ...

Re: Access NTFS qtree via NFS and usermapping problem

USER_2000 — Tue, 22 Jul 2014 19:03:25 GMT

Agreed. I overlooked that. Good point.