Freigeben über

Tips on 'mount options" on NFS version 4.1

  • Artikel

Inputs on NFS 4.1 mount:

While working on a recent scenario on NFS V4.1, we came across some intresting scenarios for mounting the NFS volumes on the Unix NFS clients.

In the implementation of V4.1, there are no particular access requirements to virtual directories , but all relative objects have the relevant security checks applied, namely checks using a combination of the object permissions and the share permissions. In this case, the root directory, namely “/” is virtual and testnfs (i.e. “c:\testnfs”) is a real object and so has normal access rules supplied.

This means that you can happily read the directory rooted at “/” as UID 0 with no particular requirements. Hence, the LOOKUP of “testnfs” relative to “/” succeeds.

 Analysis from Netmon traces:

From the entmon analysis we found that a attempt is made to issue a GETATTR against the “<NFS-share>” directory as UID 0 from the Unix NFS client. Unlike V2/V3 where GETATTR has no access requirements, V4.1 *does* require that the server verify that the requestor be checked for access for a GETATTR request. So the server will attempt to locate a Windows account matching UID 0. As there is no such mapping, it will attempt to use the Anonymous account, but since anonymous access has been disabled on the share, the attempt will be failed.

Following are the options to mount the NFS share:

  1. Create a mapping for UID 0 to a Windows account. Note this Windows account does not necessarily have to be a privileged account if it is not being used to apply the special “root” like operations. B
  2. Allow anonymous access and ensure that the permissions on the objects to be accessed in this way (possibly just the directories being “mounted”) allow access via the account being used for anonymous. However in this scenario we need to add anonymous logon in the NTFS permission.
  3. In case, we do not want to map the root user (UID 0) to an AD user, then we have these options:
    1. Enable the option “Unmapped Unix user access”
    2. Or else mount the root (“/” directory) on the Unix NFS clients.
    3. Check “Allow anonymous access”. However this will not work unless we add the anonymous logon in the NTFS permission.
    4. This is something I have not tried but can be done from the Unix side. Issue the UNIX mount in the context of the account needing access. That is, allow the UNIX user to mount the target share themselves to somewhere in their own local namespace.