Mounting NFS on a Windows Client

To set up the Windows NFS client, mount the cluster, map a network drive, and configure the user ID (UID) and group ID (GID). The Windows client must access NFS using a valid UID and GID from the Linux domain. Mismatched UID or GID will result in permissions problems when MapReduce jobs try to access files that were copied from Windows over an NFS share.
Note: Because of Windows directory caching, there may appear to be no .snapshot directory in each volume's root directory. As a workaround, force Windows to re-load the volume's root directory by updating its modification time (for example, by creating an empty file or directory in the volume's root directory).
Note: With Windows NFS clients, use the -o nolockoption on the NFS server to prevent the Linux NLM from registering with the portmapper. The native Linux NLM conflicts with the MapR NFS server.

Complete the following steps to mount NFS on a Windows client:

  1. Mount the Cluster.
    Complete the following steps for Windows 10 Enterprise
    1. Open Start > Control Panel > Programs.
    2. Select Turn Windows features on or off.
    3. Select Services for NFS.
    4. Click OK.
    5. Enable write permissions for the anonymous user because the default options only grant read permissions when mounting a UNIX share using the anonymous user.
      To grant write permissions, make a change to the Windows registry by performing the following steps:
      1. Open regedit by typing it in the search box and pressing Enter.
      2. Create a new New DWORD (32-bit) Value inside the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default folder named AnonymousUid and AnonymousGid and assign the UID and GID found on the UNIX directory as shared by the NFS system.
    6. Restart the NFS client or reboot the machine to apply the changes.
    7. Mount the cluster and map it to a drive using the Map Network Drive tool or from the command line.
      mount -o anon usa-node01:/mapr z:
      For more information, see step 2 below.
    Complete the following steps for Windows 7 Ultimate or Windows 7 Enterprise
    1. Open Start > Control Panel > Programs.
    2. Select Turn Windows features on or off.
    3. Select Services for NFS.
    4. Click OK.
    5. Mount the cluster and map it to a drive using the Map Network Drive tool or from the command line.
      mount -o nolock usa-node01:/mapr z:
      For more information, see step 2 below.
    Complete the following steps for all other versions of Windows:
    1. Download and install Microsoft Windows Services for Unix (SFU). You only need to install the NFS Client and the User Name Mapping.
    2. Configure the user authentication in SFU to match the authentication used by the cluster (LDAP or operating system users). You can map local Windows users to cluster Linux users, if desired.
    3. Once SFU is installed and configured, mount the cluster and map it to a drive using the Map Network Drive tool or from the command line.
      mount -o nolock usa-node01:/mapr z:
      For more information, see step 2 below.
  2. Map a network drive with the Map Network Drive tool.
    1. Open Start > My Computer.
    2. Select Tools > Map Network Drive.
    3. In the Map Network Drive window, choose an unused drive letter from the Drive drop-down list.
    4. Specify the Folder by browsing for the MapR cluster, or by typing the hostname and directory into the text field.
    5. Browse for the MapR cluster or type the name of the folder to map. This name must follow UNC. Alternatively, click the Browse… button to find the correct folder by browsing available network shares.
    6. Select Reconnect at login to reconnect automatically to the MapR cluster whenever you log into the computer.
    7. Click Finish.
  3. Configure the UID and GID for NFS access.
    For a system that is part of the Active Directory Domain, you must instruct the NFS client to access an AD server to get uidNumber and gidNumber.
    1. Ensure the AD Users schema has auxiliary class posixAccount.
    2. Populate AD uidNumber and gidNumber fields with matching uid and gid from Linux.
    3. Configure the NFS client to look up uid and gid in the AD DS store.
    4. Refer to details here: http://technet.microsoft.com/en-us/library/hh509016(v=ws.10).aspx.
    For a standalone Windows 7 or Vista machine (not using Active Directory), Windows always uses its configured Anonymous UID and GID for NFS access, which by default are -2. However, you can configure Windows to use specific values, which results in being able to access NFS using those values.

    The UID and GID values are set in the Windows Registry and are global on the Windows NFS client box. This solution might not work well if your Windows box has multiple users who each need access to NFS with their own permissions, but there is no obvious way to avoid this limitation.

    The values are stored in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default. The two DWORD values are AnonymousUid and AnonymousGid. If they do not exist, you must create them.

    Refer to details here: http://blogs.msdn.com/b/sfu/archive/2009/03/27/can-i-set-up-user-name-mapping-in-windows-vista.aspx.

  4. (Optional) Deactivate the nlockmgr service.
    If the nlockmgr service is active on a Windows machine, attempts to mount a MapR NFS share fail with the following message:
    C:\Users\administrator.Client1>mount -o nolock -u:mapr -p:mapr ClusterNode1:/mapr / g:
    Network Error - 53
    Type 'NET HELPMSG 53' for more information.
    1. Run the rpcinfo command to confirm that the nlockmgr service is active.
      C:\Users\administrator.Client1>rpcinfo -p ClusterNode1
      program version protocol     port
      --------------------------------------------------
      100000       4      tcp      111    portmapper
      100024       1      udp    60588    status
      100007       2      udp      817    ypbind
      100021       1      udp    47016    nlockmgr
      100021       3      udp    47016    nlockmgr
      100021       4      udp    47016    nlockmgr
      100021       1      tcp    34254    nlockmgr
      100021       3      tcp    34254    nlockmgr
      100021       4      tcp    34254    nlockmgr
    2. Check the output for the presence of nlockmgr. To deregister nlockmgr services on the node, use the -d switch in rpcinfo on the MapR node.
      [root@ClusterNode1 ~]# rpcinfo -d 100021 1
      [root@ClusterNode1 ~]# rpcinfo -d 100021 2
      [root@ClusterNode1 ~]# rpcinfo -d 100021 3
      [root@ClusterNode1 ~]# rpcinfo -d 100021 4
    3. Re-check rpcinfo output to verify that no nlockmgr services are registered. The NFS mount completes successfully at this point.
      C:\Users\administrator.Client1>mount -o nolock -u:mapr -p:mapr ClusterNode1:/mapr/ Z:
      Z: is now successfully connected to ClusterNode1:/mapr/
      The command completed successfully.                       

Configuring Access When ACES are set

Some NFS clients, such as the Microsoft native Windows NFSv3 client, check mode bits to determine if access is allowed even before contacting the NFS server. If ACEs are set on a directory or file, the client-side permission checks based solely on mode bits will prevent the client from accessing the file or directory. You can set the value for the WindowsAceSupport property to true in the nfsserver.conf file to allow the Windows client access to the file or directory. The default value for this property is false, denying the client access even before contacting the NFS server.

When the WindowsAceSupport property value is set to true, MapR returns to the client the mode bits 777 if ACE is set on the file or directory, thus allowing the client to establish a connection to the server. However, when the client actually tries to read or write from the server, MapR performs permission checks against the mode bits and ACEs on the directory and/or file, ensuring proper access.

Note: When set to true:
  • Tools that visually display access information might show read/write access for user who do not have that access.
  • Files that are not executables might appear so.
  • NFSv3 client cannot be used to access NFSv4 server because the NFSv4 server only supports the v4 protocol.