Mounting NFS on Windows 10 clients

TL;DR: Install NFS client feature (either from features menu or via DISM in an elevated command prompt), use the mount and umount command to mount and unmount via NFS in case anonymous user mapping is used.

• Introduction
• Installing the NFS client
• Mounting
  • Anonymous
  • Unauthenticated, with user mapping, no AD, no Kerberos
  • With Kerberos

Introduction

Sometimes one just encounters Windows machines even if one tries to avoid this as good as possible. Then sometimes one wants to allow them to access network shares on a local network - Windows users are usually using the SMB protocol using WINS to locate the machines. It’s entirely possible to support these protocols using samba (and even possible running the LDAP / Kerberos suite that’s called active directory by Microsoft even though that’s a little bit of work). On the other hand it’s most of the time simpler to support NFS on the clients instead of rolling out a second file sharing protocol in parallel. Fortunately Microsoft now supports NFS even on more consumer side versions (professional edition) of Windows and not only on the enterprise versions as before - though up to my knowledge there is no way to mount NFS shares on home editions (but since they also do not support different users for SMB, etc. they’re pretty much useless as soon as one runs a network anyways). This blog post gives a short summary on how to mount NFS shares on Windows machines (basically a note to myself how to do this stuff).

Installing the NFS client

First of the NFS client is only supported since Windows 10 professional in the professional versions, older versions (though they should not be in operating networked anywhere anyways) one would require the enterprise versions.

One can either just use both Client for NFS and Administrative Tools from the Services for NFS in Windows features dialog to install the NFS client of use DISM from an elevated command prompt:

dism /online /Enable-Feature /FeatureName:ServicesForNFS-ClientOnly
dism /online /Enable-Feature /FeatureName:ClientForNFS-infrastructure
dism /online /Enable-Feature /FeatureName:NFS-administration

Mounting

Anonymous

If one has exported a share with a typical anonymous mapall mount (i.e. one that has a -mapall=username value set in the /etc/exports on the server) one can simply mount from a command prompt using

mount -o anon \\server\path\to\directory DRIVE:

In case one wants to mount

• The share /nfs/testdata
• On nas.example.com
• Onto drive x on the windows machine

this would be

mount -o anon \\nas.example.com\nfs\testdata x:

One can control the UID and GID that Windows is using for anonymous mounts using the registry keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default\AnonymousUID and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default\AnonymousGID (both are DWORD keys and accept the numeric user id and group id). Note that changing these settings only takes effect after a reboot of the machine or a restart of the NFS service.

Unauthenticated, with user mapping, no AD, no Kerberos

In case one wants to use NFS in the old 90’th way without authentication (privileged ports have been considered trusted since the client has been considered trusted and Kerberos has not been a thing back then) one has to create the user and group mappings Windows is using for it’s mountpoints. This is done using a passwd and groups file at C:\windows\system32\drivers\etc\passwd and C:\windows\system32\drivers\etc\group

The typical format of lines inside these files is for passwd:

[USERNAME]:x:[UID]:[GID]:[GECOS],,,:c:\users\[USERNAME]

and for group:

[GROUPNAME]:x:[GID]:[UID]

For example in case one wants to identify the user exampleuser with the Unix UID 1234 and the GID 567 the entries might look like the following:

exampleuser:x:1234:567:Just an example user,,,:c:\users\exampleuser

and

examplegroup:x:567:1234

Please note that the parser is rather picky:

• No empty lines at the end of the file or somewhere in between
• No extra blanks at the end of lines
• No duplicated users
• No non existing users

With Kerberos

This is by far the best idea. I won’t cover the setup of Kerberos in one’s network in this blog post since this is a little bit more complex (it requires correctly configured DNS and reverse DNS, a running KDC, etc.) but it’s totally worth it. In case one has not configured Kerberos or user mapping one just has to perform the standard setup sequence for Kerberos on the Windows client:

ksetup /setdomain EXAMPLE.COM
ksetup /setmachpassword <your kerberos password>
ksetup /addrealmflags EXAMPLE.COM sendaddress delegate
ksetup /mapuser * *

The last step maps all users from the network by name to local users. One can few the current state of Kerberos:

ksetup.exe / DumpState

To check if a user is capable of getting a Kerberos ticket one just as usual uses klist to list current tickets.

Mounting an NFS share works similar to anonymous mounting - just specifying Kerberos as security layer:

mount -o sec=krb5 server:/path/to/directory DRIVE:

Again using the same example:

• The share /nfs/testdata
• On nas.example.com
• Onto drive x on the windows machine

mount -o sec=krb5 nas.example.com:/nfs/testdata x:

This article is tagged:

• System administration
• Windows
• Network