Access NTFS qtree via NFS and usermapping problem

[USER_2000]

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?

[FIZEE_DISNEY]

@parisi : This is an interesting post and thanks for contributing.Could you please upload the images that was missed out?

[parisi]

I don't have the original images, but I have images that show the same behavior from traces I've saved.

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

Example:

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:

This differs from the reply returned by NFSv3:

Hopefully that clarifies things. I can include the other images if needed, but you would see the behavior already described:

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

[FIZEE_DISNEY]

Thanks Parisi.

So as per the below document,

NFSv4 Enhancements and Best Practices Guide: Data ONTAP Implementation

NFSv3, client-server communication happens using a numeric user ID and group ID (UID/GID) .

      UID/GID used for mapping and allowing for operations. However if UID/GID mapping is not found in /etc/passwd or NIS or LDAP then ownership is assigned to nfsnobody.

      This doesnt go with strings check.

NFSv4 does not support UID or GID; it supports string-based communication for users and groups between the server and the client.

                 It actually makes use of UID and GID to storage side mapping(/etc/passwd or NIS or LDAP) and then uses strings for correct UID assignee( or else goes with default nfsnobody).

                  If the parameter  nfs.v4.id.allow_numerics set to "on" similar behavior as NFS v3 should be seen.

Correct me if i am wrong.

[parisi]

Out of the box, NFSv4 does not support UID/GID (meaning, "use numerics" is disabled by default). The "use numerics" is a workaround to allow this behavior, but defeats the notion of name string as a security feature of NFSv4.

The NFSv4 server will collect the information from the client (as seen in the trace). The client will send a UID/GID. It is then up to the NFSv4 server to translate that UID/GID string into a valid user string. If it cannot find one, or if it does not match what the client sees the UID/GID as, then the user gets mapped to nfsnobody, nobody, etc. (whatever is set in the idmapd.conf file)

The strings check happens during the interaction between client and NFS server. Using numerics bypasses that check to allow for proper translation of the UID/GID on the client regardless of what is seen on the NFS server/name service server.

Does that help clarify?

[FIZEE_DISNEY]

Thanks a ton Parisi. It helped me alot.

[timparkinson]

Is this behaviour ONTAP version specific?

We're actively trying to use numerics only for one reason or another, we have the -v4-numeric-ids option enabled, but although the client is only sending numerics, the filer always sends back the textual version (from a packet trace). The uid is being correctly translated to username in this response, but what we really want is just the uid back. We're using 8.2.2RC2