Windows Server NFS: Identity Mapping, Kerberos, and Share Operations

Windows Server can act as both an NFS server and an NFS client, which is useful in mixed Windows, Linux, and UNIX environments. That interoperability does not make NFS access equivalent to SMB. Protocol versions, authentication, UID/GID mapping, share-level host permissions, Windows ACLs, name resolution, and client mount options all contribute to the effective result. A successful mount proves reachability and some level of export access; it does not prove that user identity and write authorization match the organization’s intent.

Start a deployment by deciding which side is the server, which NFS version each endpoint supports, and how identities will map. Windows Server’s Server for NFS supports NFSv2, NFSv3, and NFSv4.1; the Windows NFS client supports NFSv2 and NFSv3. A Windows client therefore cannot be assumed to mount an NFSv4.1-only export. Confirm exact versions for the deployed Windows Server release and the non-Windows implementation before changing server settings.

Separate the NFS server and client roles

Server for NFS exports directories from Windows Server to NFS clients. Client for NFS allows a Windows computer to access exports on an NFS server. The roles can be installed on different systems and have different configuration, service, firewall, and identity requirements. Record which component is installed on each host rather than using “NFS is installed” as a complete description.

Install Server for NFS through the supported role-management workflow and include management tools if administrators need the console or PowerShell module. A representative role installation command is:

Install-WindowsFeature -Name FS-NFS-Service -IncludeManagementTools
Get-WindowsFeature -Name FS-NFS-Service

Verify the feature result and reboot requirement for the target system before advertising the service. In a production file server, first check the server role, storage path, backup, firewall baseline, cluster configuration, and existing NFS export list. Do not install the server role on a general-purpose workstation as a shortcut for an application that only needs NFS client access.

Choose authentication before creating the export

NFS authentication determines how a client proves an identity, while identity mapping translates between UNIX numeric identifiers and Windows security principals. They are related but not interchangeable. AUTH_SYS sends numeric UID and GID claims from the client and depends on a trusted network and consistent identity assumptions. Kerberos provides stronger authentication; Windows Server exposes krb5 for authentication, krb5i for integrity protection, and krb5p for privacy protection. Microsoft recommends Kerberos for NFSv3 and NFSv4.1 scenarios.

Select the Kerberos protection level with the data’s confidentiality and performance requirements in mind. krb5 authenticates the user but does not by itself promise payload integrity or privacy; krb5i protects integrity; krb5p adds privacy protection. The actual security depends on both server and client support, domain/SPN configuration, DNS, time synchronization, and the way the client mounts the export. Test the exact version and security flavor with the real client implementation.

Avoid broad unmapped or anonymous access as a workaround for a mapping failure. Those settings can make a mount succeed while mapping users to an unintended identity. On a shared server, an incorrect identity can turn a seemingly harmless read test into cross-user write access. Decide whether unmapped users should be denied, mapped to a deliberately restricted account, or supported through a documented deployment design before creating the share.

Plan UID/GID mapping as an access-control system

UNIX permissions use numeric UIDs and GIDs. Windows ACLs use security identifiers. Windows Server can use mapping data stored in Active Directory, AD LDS or an RFC 2307-compatible LDAP source, a configured mapping service, or local mapping files depending on the deployment. The chosen mapping store must be available and consistently administered by the server that evaluates access. Duplicate numeric IDs or stale account maps can expose the wrong file owner even if the pathname is correct.

Document the mapping table, primary and supplementary groups, service accounts, and expected Windows ACL outcome. Test a normal user, a group member, an unmapped user, and an administrative identity. Validate both directions: a Linux client-created file should show the expected owner/group on Windows, and a Windows-created file should be accessible with the intended UNIX identity. Do not use a privileged account as the only test because its broad rights can hide a mapping defect.

The NFS PowerShell module exposes mapping operations. For example, a mapped identity can associate a UNIX UID/GID with a Windows account in an AD-backed store. Treat the following as a lab-shaped example, not a production identity recommendation:

Get-NfsMappedIdentity -MappingStore AD -AccountType User -AccountName 'svc_nfs_build'

# Example shape only; verify UID/GID ownership and directory ACLs first.
New-NfsMappedIdentity -MappingStore AD -Server 'CONTOSO' `
    -UserName 'svc_nfs_build' -UserIdentifier 51020 -GroupIdentifier 5100

The account names and numeric identifiers must come from the authoritative identity plan. Verify that the mapping store is the one configured on the NFS server and that required user/group objects and group memberships already exist. Never use a sample UID such as 500 blindly; it may already identify another user in a Linux namespace.

Create the backing directory on a supported volume, set its Windows ACLs, then create an NFS export with an explicit authentication and permission policy. New-NfsShare can configure authentication types and a global “All Machines” permission. A broad global permission should not substitute for host or client-group restrictions where the server requires a narrower policy.

$shareName = 'build-artifacts'
$sharePath = 'D:\Nfs\BuildArtifacts'

New-Item -Path $sharePath -ItemType Directory -Force | Out-Null
Get-Acl -LiteralPath $sharePath | Format-List Owner, AccessToString

# Use the approved Kerberos flavor and a restricted access policy for the environment.
New-NfsShare -Name $shareName -Path $sharePath `
    -Authentication krb5i -Permission ReadOnly -EnableUnmappedAccess $false

Get-NfsShare -Name $shareName | Format-List *
nfsshare.exe $shareName

The example intentionally starts read-only; switch to read/write only after a test client proves correct identity mapping and ACL behavior. The cmdlet’s -Permission parameter sets global “All Machines” permission. Configure specific host, netgroup, or client-group permissions in the supported management surface and verify the effective export. In clustered deployments, include the intended network name when managing a share. Record the export name, path, authentication list, access policy, identity store, and ACL before changing it.

NFS access is evaluated across multiple layers. The client must reach the server and be allowed by the export policy; the request must authenticate or map according to the selected flavor; the target directory ACL must permit the mapped principal; and the requested operation must be compatible with filesystem semantics. On Windows, Get-Acl shows Windows security descriptors, not the complete NFS client identity story. Validate effective behavior from an actual client using the actual mount options.

Diagnose mount, read, and write failures by layer

If name resolution fails, compare the client resolver result with the intended NFS server address. If TCP reachability or port mapping fails, inspect the server role, host/network firewall, client and server protocol versions, and the deployment’s NFS service ports. Do not open every high port on the server by default; use the official deployment requirements and the organization’s segmented network policy.

If the client mounts but receives Permission denied, inspect the authentication flavor negotiated, UID/GID mapping, share permissions, root-access policy, and Windows ACLs in that order. A client’s root user is not automatically Windows Administrator. Root access is a separate share setting and should remain disabled unless an explicit workload needs it and the security owner approves the exposure. AUTH_SYS identity claims can be spoofed by a client administrator; avoid relying on them across an untrusted network.

If reads work but writes fail, test file creation in a designated non-production directory, then inspect directory-level write/execute permissions, owner/group mapping, NFS share permission, and file-system read-only or disk state. Creation can be permitted while rename or delete fails because parent directory rights and protocol behavior differ. Test create, read, rename, delete, locking, and large-file behavior rather than concluding that one touch test proves the export is fully compatible.

If the client sees unexpected ownership, capture the numeric UID/GID on the client and the corresponding mapped account on Windows. Compare the mapping source, domain/LDAP reachability, stale caches, group membership, and Windows ACLs. Changing an owner or enabling unmapped access before recording evidence can obscure the original mismatch. Make one controlled change, remount or refresh as required by the client, and verify with the same test identity.

Monitor operations without over-logging

Capture the export inventory and mapping store before a change. The NFS server can log activities such as mount, read, write, create, delete, lock, and unlock, but enabling every audit category on a busy file server can generate significant volume. Start with the narrowest useful event categories and a bounded reproduction. Protect logs because they can contain user identities, client names, and paths.

Correlate client mount output, server-side NFS events, Windows Security/NTFS events where relevant, network firewall logs, and application errors using synchronized clocks. Preserve the exact error text and operation that failed. A mount timeout, authentication rejection, mapping mismatch, ACL denial, and server-side lock contention are distinct conditions. Changing all of the authentication, export, and ACL settings together makes root cause harder to establish.

Before modifying a live share, save the current Get-NfsShare output, associated permissions, Get-Acl result, identity mappings, server version, and client mount configuration. Use a canary export or test directory first. Avoid deleting and recreating a share as a generic repair because this can change permissions, authentication, name, and client expectations at once.

Test compatibility and recovery

Test the exact NFS version, authentication flavor, client OS, client mount options, character translation requirements, file naming, ownership, locking, and application access pattern. Windows Server supports NFSv4.1 and older versions on the server, while its built-in client has a narrower set; mixed fleets can therefore require distinct server-side compatibility choices. Confirm protocol support from current product documentation rather than a connection that happens to succeed using a fallback version.

Validate backup, restore, failover, and service restart behavior. If a server or clustered network name changes, confirm clients resolve and reconnect to the intended endpoint. Verify how open files and locks behave under the chosen protocol. Perform a restore test that preserves security and identity expectations, not only file bytes. A technically successful migration can still fail operationally if the UNIX ownership map is missing on the destination.

NFS operations checklist

Identify the Windows NFS server/client role and exact protocol versions on both ends.
Select authentication and mapping sources before exporting data.
Set explicit export permissions, root policy, and Windows ACLs; avoid broad anonymous/unmapped access.
Test normal, unmapped, read-only, read/write, rename, delete, and ownership behavior from representative clients.
Capture mappings, share state, events, and client mount options before repairs.
Validate backup, restore, clustered access, and restart behavior with the same identity model.

Windows Server NFS is most reliable when treated as a cross-platform identity and authorization boundary, not merely a protocol service. A correct deployment aligns client version, Kerberos or AUTH_SYS policy, UID/GID mapping, export access, and NTFS ACLs and then tests each operation from the client identity that will use it.

Related:

Sources: