Mounting NFS folders in Windows using the built-in client
Modern versions of Windows have a built-in NFS client that allows you to directly mount NFS directories from Linux hosts or NAS devices and gain transparent access to files and folders on them. In this article, we’ll show you how to enable the NFS client in Windows, mount an NFS network share, and discuss the specifics of mapping Windows users to Linux user UIDs/GIDs.
Installing an NFS client on Windows
Starting with Windows 10, a built-in NFS client is available for mounting NFS network shares. The NFS client is not installed by default. You can enable it through the Windows Features control panel ( optionalfeatures ): expand Services for NFS and enable the Client for NFS option (you can also install NFS administrative tools).
Or you can install the NFS client using PowerShell.
On desktop platforms (Windows 10 and 11):
Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart
On Windows Server:
Install-WindowsFeature NFS-Client
Display all NFS client settings in Windows:Get-NfsClientConfiguration
Mounting an NFS network folder in Windows
You can mount an NFS network share in Windows directly from the Windows Explorer graphical interface, just like a regular network share. Select the Map network drive option in File Explorer, specify the network path to the NFS directory (in standard UNC format, for example \\192.168.158.147\nfsshare ), and specify the drive letter to assign to this drive.
However, in this mode, it is not possible to set additional options for connecting to the NFS share.
It is more convenient to mount NFS folders from the command line using:
- Console utility
mount.exe - PowerShell cmdlet
New-PSdrive
Please note that when running the mount command from the PowerShell console or Windows terminal, you must specify its full name, including the extension: mount.exe . This is because in PowerShell, the mount command is an alias for the New-PSDrive cmdlet.
Open a command prompt (or PowerShell console) with user rights ( not administrator!!!, otherwise the mounted NFS drive will not be visible in the user explorer, more details on this in the article about accessing network drives with administrator rights ).
Run the command to mount the NFS directory:
mount.exe -o anon \\192.168.158.147\nfsshare K:
-
-o anon– Connect the NFS folder under an anonymous user -
192.168.158.147– NFS server address/name -
/nfsshare– the local path to the directory on the NFS server. If a Linux host with NFS3 is used as the NFS server, then you need to specify the full local path to the NFS directory from the root of the file system, for examplehost:/mnt/nfs/nfsshare1 -
N:— the drive letter you want to assign to the folder
casesensitive=yesOr the PowerShell equivalent of the NFS mount command:
New-PSdrive -PSProvider FileSystem -Name N -Root \\192.168.158.147\nfsshare -Persist
The Persist option specifies that the connection to this NFS directory should be restored automatically after the computer is rebooted (the mount.exe command does not have this option)
You can now access files on an NFS network share directly from Windows Explorer and other applications. Note that in the properties of objects in an NFS share, Explorer displays a new tab, NFS Attributes, where you can view information about file permissions and ownership.
Also, keep in mind that if a file name on an NFS share contains Cyrillic (or other international characters), it may not be displayed, or the file name may appear as gibberish. As a workaround, you can enable UTF-8 support in Windows (still in beta): intl.cpl -> Administrative -> Change system locale -> check the Beta: Use UTF-8 to support languages worldwide checkbox.
Unmount the NFS network share:
Remove-PSDrive N
Or
umount.exe K:\
Run the command mount.exe to display the options with which the NFS directory is mounted:
When connecting anonymously to an NFS server, Windows uses UID=-2 and GID=-2 by default to map the connecting user to a user on the remote server. If you want to use a specific Linux user UID/GID for anonymously mounting an NFS directory, you can override these values using the AnonymousUid and AnonymousGid parameters in the registry key HKLM\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default . For example, the following parameters will force the NFS client to use UID=0 and GID=0 ( root the Linux user) for anonymous connections instead of the default -2:
reg add "HKLM\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" /v AnonymousUid /t REG_DWORD /d 00000000 /f
reg add "HKLM\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" /v AnonymousGid /t REG_DWORD /d 00000000 /f
After making the change, you need to restart the NFS services:
Restart-Service nfsrdr,nfsclnt -Force
However, using anonymous NFS access isn’t the most secure solution. It’s better to map Windows users to Linux user UIDs and GIDs :
In an AD domain, you can enable user mapping:
Set-NfsMappingStore -EnableADLookup $true
Set-NfsMappedIdentity -MappingStore AD -UserName "kbuldogov" -UserIdentifier 1000 -GroupIdentifier 100
Or edit the uidnumber and gidnumber parameters in the AD user attributes.
Set-ADUser -identity user1 -replace @{uidNumber="<user_uid>";gidNumber="<user_gid>"}
On stand-alone machines (in workgroups, or when you don’t want to use AD mapping), you can configure Windows username to Unix UID/GID mapping via the passwd and group files in the C:\Windows\System32\drivers\etc .
For example, for local user user1:
Passwd file :
user1:x:1000:100:User1:C:\Users\user1
Group file :
users:x:100:user1
You can check the mapping of a specific Windows user to the Linux UID/GID using the command:
Get-NfsMappedIdentity -AccountName user1 -AccountType User
