Netwrix and Stealthbits merge to better secure sensitive data. LEARN MORE

Mounting NFS Exports from a Unix Server on Windows 10 or Windows Server

Blog >Mounting NFS Exports from a Unix Server on Windows 10 or Windows Server

While you’re more likely to be familiar with accessing network file shares via Server Message Block (SMB), or the Windows implementation of SMB (CIFS), the Network File System (NFS) is still prevalent in modern production environments, such as on Unix servers like NetApp ONTAP and Dell EMC Isilon/PowerScale OneFS.

Originally designed in 1984 at Sun Microsystems with roots in Unix, NFS is an open standard for distributing a file system across a network for multi-client access. Currently at version 4.2, NFS has grown to include many authentication methods at both the share (known as an “export” in NFS terms) and file system levels, including client IP/hostname, auth_sys (Unix auth), Kerberos, and NFSv4.x ACLs.

NFS is a powerful protocol, however it traditionally has not played well with environments that mix Windows with Unix. To enable Windows client access to NFS exports, each NFS export would also need a Samba share equivalent (an SMB implementation for Unix).

However, this changed when Microsoft implemented NFS client and server tools. As of the time of this blog, Microsoft’s NFS documentation lists the following operating system support:

Operating Systems NFS Server Versions NFS Client Versions
Windows 7, Windows 8.1 Windows 10 N/A NFSv2, NFSv3
Windows Server 2008, Windows Server 2008 R2 NFSv2, NFSv3 NFSv2, NFSv3
Windows Server 2012, Windows Server 2012 R2,
Windows Server 2016, Windows Server 2019
NFSv2, NFSv3, NFSv4.1 NFSv2, NFSv3

How to Configure Windows as an NFS Client

First, we need to enable certain features within Windows in order to perform NFS client operations. The easiest way to do so is in an elevated PowerShell session, and the command differs depending on if our client environment is running Windows 10 or Windows Server.

For Windows 10:

Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart

For Windows Server:

Install-WindowsFeature NFS-Client

That’s it! Now we’re ready to mount NFS exports from a Unix server. However, we’re likely to only have read access (assuming our IP is granted access to the NFS export in the first place) due to how UID/GID mapping works between Windows and Unix.

To solve this, there are a few ways we can perform identity mapping (Windows user vs. Unix UID/GID). There’s also a useful PowerShell command we can run at any time that will check the current Windows user’s UID/GID mapping configuration:

>> Get-NfsMappingStore

UNMServer               :
UNMLookupEnabled        : False
ADDomain                :
ADLookupEnabled         : False
LdapServer              :
LdapNamingContext       :
LdapLookupEnabled       : False
PasswdFileLookupEnabled : False

Before we go over identity mapping methods, let’s first discuss what Unix UIDs and GIDs are and how they relate to Windows users when mounting NFS exports.

What Are Unix UIDs & GIDs?

In Unix-like operating systems, such as Linux, users and groups are identified by user identifiers (UID) and group identifiers (GID) respectively. From an operating system perspective, UIDs and GIDs are what give users and groups access to resources on the system, such as files and folders.

For both UIDs and GIDs, 0 is reserved for root, 1-999 are reserved for system accounts and services, and 1000+ are for user accounts. If you were to run the id command on the command line as the first user configured on a new Linux host, you’d probably notice both the UID and GID are 1000.

danp@new-ubuntu:~$ id
uid=1000(danp) gid=1000(danp) ...

As users get created, UIDs and GIDs should continue to match. 1001 (UID) / 1001 (GID), 1002 (UID) / 1002 (GID), etc.

So why is this important to mounting NFS exports on Windows clients? Well, Windows uses entirely different mechanisms for identifying users and groups (Security Identifiers, aka SIDs). UIDs and GIDs are not a concept on Windows, at least not until recently when NFS client functionality was added to that operating system.

In order to properly authenticate to a Unix server providing NFS exports, we’ll need to perform identity mapping on our Windows client in order to convert a user’s Windows representation of its identity to a Unix identity representation. Essentially, we need to map Windows users to Unix UIDs and GIDs, so when an NFS export is requested the Unix server is able to properly understand which user is making the request.

There are a few different ways we can achieve this, which we’ll go over next.

Identity Mapping Methods for Windows NFS Users & Unix UID/GIDs

1. Active Directory (AD)

If both the Unix NFS server and Windows NFS client are joined to the same Active Directory domain, then we can handle identity mapping in Active Directory. This is the preferred method for security purposes when possible.

NOTE: This method is not available if method #2 (below) is in use, as the presence of a local \etc\passwd file will take precedence for identity mapping.

By default, our NFS client won’t look up identity mapping in Active Directory, however we can change that with the following command in an elevated PowerShell session on the NFS client:

» Set-NfsMappingStore -EnableADLookup $True -ADDomainName "<your_domain>"

Now if we run the Get-NfsMappingStore command again, we’ll see ADLookupEnabled is now True, and we have a domain specified for ADDomain.

» Get-NfsMappingStore

UNMServer               :
UNMLookupEnabled        : False
ADDomain                : <your_domain>
ADLookupEnabled         : True
LdapServer              :
LdapNamingContext       :
LdapLookupEnabled       : False
PasswdFileLookupEnabled : False 

Next, we’ll need to configure our identity mapping in Active Directory Users and Computers.

To view uidNumber and gidNumber attributes for each user, make sure you have Advanced Features enabled under the View dropdown:

Advanced Features enabled under the View dropdown

You’ll then be able to view and edit those fields in a user or group’s Properties menu, on the Attribute Editor tab.

Group properties Attribute Editor Tab

It can be cumbersome to manually map UIDs and GIDs for many Active Directory users, however there are PowerShell commands that help script/automate this process based on a UID/GID CSV export from an AD-joined Unix NFS server.

For example:

Set-ADUser -identity <UserPrincipalName> -add @{uidNumber="<user_unix_uid>";

With UID/GID data for many users imported to the PowerShell session from a CSV, this command can be looped through to set the appropriate attribute values for each desired user.

NOTE: In the Set-ADUser command, “add” should be changed to “replace” if a user already has a value for either uidNumber or gidNumber.

Using this approach, we can now mount an NFS export to an available drive letter via Command Prompt, and the UID/GID will be mapped per the current Active Directory user’s uidNumber and gidNumber attribute values.

» mount \\<nfs_server_ip_address>\path\to\nfs\export Z:

The path after the NFS server’s IP is the local path to the NFS export on the NFS server, and the drive letter is any available drive letter on the Windows NFS client.

Of course, the Unix rights given to the user we’ve mapped to ultimately decide what kind of access we have to the export, such as read/write or read-only.

2. Local \etc\passwd file

The previous method utilizing Active Directory is preferred, so we won’t go into detail for this approach. However, it’s worth stating that Windows can perform local identity mapping using Unix-style passwd and group files, located in %SYSTEMROOT%\system32\drivers\etc.

If the passwd file is present and has identity mapping information for the current Windows user, then the mappings specified in the passwd and group files will be used for the client’s NFS mount requests rather than UID/GID mappings in Active Directory or the AnonymousUid/AnonymousGid Windows registry settings outlined below.

When running the Get-NfsMappingStore PowerShell command, you’ll notice PasswdFileLookupEnabled is True whenever this workflow is in effect for the current Windows user.

This approach uses the same mount syntax as the Active Directory identity mapping approach above:

» mount \\<nfs_server_ip_address>\path\to\nfs\export Z:

3. AnonymousUid/AnonymousGid Windows registry settings

This final method is simple but potentially allows any local user to mount the target NFS export(s) with read/write access, as opposed to securing write permissions to specific local Windows users via the methods above. For this reason, this is considered an insecure approach and is not recommended.

To map the local Windows client to the UID and GID of the Unix user that owns the desired export(s), we’ll run the following in an elevated PowerShell:

» New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value <unix_export_owner_uid> -PropertyType "DWord"

» New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value <unix_export_owner_gid> -PropertyType "DWord"

After adding these keys to the Windows registry, reboot to have them take effect.

After, the following Command Prompt command will mount the desired NFS export with read/write access (assuming the client’s IP has permission to mount the export, and that the UID/GID mapping is correct for each desired export):

» mount -o anon \\<nfs_server_ip_address>\path\to\nfs\export Z:

Stealthbits – Now Part of Netwrix


Stealthbits – now part of Netwrix – is a customer-driven cybersecurity software company focused on protecting an organization’s sensitive data and the credentials attackers use to steal that data. By removing inappropriate data access, enforcing security policy, and detecting advanced threats, our highly innovative and infinitely flexible platform delivers real protection that reduces security risk, fulfills compliance requirements, and decreases operational expense.

For more information, please visit

Featured Asset

Leave a Reply

Your email address will not be published. Required fields are marked *





© 2021 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.