Windows Nfs Share Permissions

I have a NFS share setup on FreeNAS 9.10 and trying to figure out how to connect to it from a Windows 10 Pro machine. As I understand only Windows 10 Professional has the service for NFS built in so in my case I can't figure out what I need to do.

Describes how to mount an NFS share on a Windows client, and configure the relevant user and group IDs.

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 results in permission problems when MapReduce jobs try to access files that were copied from Windows over an NFS share.

Due to Windows directory caching, the .snapshot directory may not appear in the root directory of each volume. As a workaround, you can 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).

With Windows NFS clients, use the -o nolock option 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 as 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_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefault 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. For more information, see step 2.
    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. For more information, see step 2.
    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. For more information, see step 2.
  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 Browse… 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 that the AD Users schema has auxiliary class posixAccount.
    2. Populate the AD uidNumber and gidNumber fields with the 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_MACHINESOFTWAREMicrosoftClientForNFSCurrentVersionDefault. 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:
    1. Run the rpcinfo command to confirm that the nlockmgr service is active.
    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.
    3. Re-check rpcinfo output to verify that no nlockmgr services are registered. The NFS mount completes successfully at this point.

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 Access Control Expression (ACE)s are set on a directory or file, the client-side permission checks based solely on mode bits 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, and denies access to the client even before contacting the NFS server.

When the WindowsAceSupport property value is set to true, MapR returns mode bits 777 to the client 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 the WindowsAceSupport property value is set to true:
  • Tools that visually display access information might show read/write access for users who do not have that access.
  • Files that are not executables might appear executable.
  • You cannot use the NFSv3 to access an NFSv4 server, because the NFSv4 server only supports the v4 protocol.

There are times when you need to access some Windows shares from Linux machines, or systems that have some Linux variations. A few methods exists on how you can do this, and NFS (Network File System) is one of them. NFS exists for a long time in Windows, starting with server 2003, and it’s still here in server 2012/R2. By sharing a folder using the NFS protocol, Linux users can map that share on their systems and use it as a central location for their documents. The only downside of using NFS is that you can’t have that granular control on those shares like you have in Windows, but usually read-write and read-only are enough.

Share

Let’s begin by installing NFS on Windows, so open Server Manager, go to Manage and click Add Roles and Features.

Follow the wizard until you reach the Server Roles page. Here check the Server for NFS box under the File and Storage Services > File and iSCSI Services. You might also want to enable the File Server Resource Manager role if you want use some advance features of NFS.

Click Install to begin the installation.

If you want to do this using PowerShell, use the following command:

Using this command will also install the File Server Resource Manager role. Right now we are ready to share a folder using NFS, and there are three methods to do this: the classic one, the wizard one and the PowerShell one.

Configuring NFS shares using the Manage NFS Sharing option

As a tip, before we get started, do not name your directory that you want to share ‘NFS Share‘, or you will get an error when configuring permissions:

Server for NFS cannot update the share configuration. Try updating the shared directory again, or delete and recreate the shared directory

I found this during my testing, and I taught, why not share this with you! Now open the properties of a folder you want to share using the NFS protocol and go to the NFS Sharing tab. Here click the Manage NFS Sharing button.

On the new window check the Share this folder box. Now all of the other options and settings are available and ready to be configured. If you want to change the proposed share name which is the name of the the folder, you can do this from the Share Name box. Among the authentication options you can choose Kerberos v5 [Krb5] which uses the Kerberos v5 protocol for authentication, Krbv5i which provides integrity checking to verify that authentication data has not been altered, and Krb5p which provides privacy (new addition for Windows Server 2012). Unmapped user access is useful for scenarios where integration doesn’t occur between the clients accessing the shares. Unmapped user access has other two options: anonymous and unmapped user access. With unmapped user access, the server for NFS creates custom SIDs that correspond to the UIDs and GIDs for the UNIX accounts accessing the share. If you are using anonymous you need to put the power of Windows Firewall in place to deny access to the NFS service from all but the required IP addresses or subnets. Usually you don’t have to change these settings and just go with the default ones.

For more advanced share permissions click the Permissions button. This is where you can allow or deny computers form the network to connect to the NFS share, and where you set the access type for those computers. To allow them to connect, click the Add button, and in the Add Names box type the name or IP addresses of the clients you want to be able to connect to the share. You can add multiple clients at once, just separate them with a semicolon (;). Leave the type of access to Read-Write because this will be controlled using NTFS permissions anyway.

When you add multiple clients in the list and separate them with a semicolon, make sure no spaces exist in front or after that semicolon, or you will get an error message that then name cannot be resolved. Long story short… no spaces are allowed in that list.

Before you map this from a Linux client you need to set the proper NTFS permissions, or the client will not be able to read the share even tough is in the IP allow list. Switch to the security tab and add Everyone with the default permissions. If you want clients to be able to modify or write in this share, set the permissions to Modify and Write. The final access on the share is determined by both, the NFS permissions and the NTFS permission; the most restrictive permission wins. For more information on how NFS access works over NTFS permissions read this Microsoft Technet article.

Configure NFS shares using the Server Manager Wizard

This method is not valid for Windows operating systems older than server 2012. For those, you need to use previous method. Now open Server Manager, go to File and Storage Services and here click on Shares.

From the Shares section click Tasks > New Share.

The New Share Wizard opens. On the first screen select NFS Share – Advanced; because going with NFS Share – Quick we don’t get all the options and goodies.

Here is where you provide the share location. You can share the an entire volume by selecting it under the Select by volume section, or you can share a specific folder, by using the Type a custom path radio button.


In case you want to change the proposed share name, you can do it here from the Share name box. The remote share path will be automatically modified/completed for you.

On the Authentication page, chose the authentication protocols you want to use for this share then click Next.

Click the Add button to open the Add Permissions window. In the Host box, type the IP address or IP addresses for those Linux machine(s) that connect to this share.

And here are the NTFS permissions for this folder. As you can see the Everyone group is already in the list with Modify permissions. If you just want Read permissions for this share, select the Everyone group and click the Customize Permissions button.

On the Management Properties page, you are given the option to select what type of files are kept in this shared folder; for data management policies.

From this page you can set a quota for the folder. In case the already available quota templates are not good for you, no worries, you can customize the quota or create a new one after the folder is shared using the File Server Resource Manager console.

Windows 2016 nfs share permissions

Click Create to share this folder using NFS.

Windows

At the end you should have some nice graphics that tells you how much space is used on the share and how is the quota limit staying (if you applied one). And that’s it, your folder is shared using the NFS protocol.

Configure NFS shares usingPowerShell

Just in case you are a scripting person, here is a simple PowerShell line that enables NFS sharing on a folder with the default settings:

New-NfsShare-Name"YOUR SHARE NAME"-Path"YOUR FOLDER PATH"-AllowRootAccess$false-Permission ReadOnly-Authentication all

You can also put ReadWrite for everyone but is better to do this on a per machine basis, and here is how:

Grant-NfsSharePermission-Name"YOUR SHARE NAME"-ClientName"YOUR LINUX CLIENT IP"-ClientType"host"-Permission"readwrite"

Now that the share permissions are in place, the next step is to configure the NTFS permissions. Follow this Microsoft Technet article on how to do it using PowerShell, or if you are in a hurry use the GUI to test this. Again, between the share permission and NTFS permissions, the one that is more restrictive wins. That’s why I set the share permissions to Read-Write so I can control the effective permissions trough NTFS.

Now log in to one of your Linux clients and open a terminal with root permissions. Go to your favorite path and create a new directory here using the mkdir command. This is needed in order to mount the Windows NFS share.

To mount the NFS share to the directory that was just created use the following command:

Windows Nfs Share Permissions All Machines

mount YOUR NFS SERVER:/YOUR NFS SHARE DIRECTORY/YOUR MOUNT FOLDER

And here it is, the Windows share mounted on a Linux client. As you can see the client has Read-Write permissions, since it’s able to create files and folders in this share.

To make the mount permanent you will have to edit your /etc/fstab file, if not, the share will be un-mapped after reboot and you will have to use the mount command again.

This is all there is. Use whatever method you are more comfortable with because they all have the same result.

Want content like this delivered right to your

email inbox?

Windows Server 2016 Nfs Share Permissions


More similar articles