How to Configure NFS on Win2003

— ny_wk

To configure NFS on Windows Server 2003 you install Microsoft Windows Services for UNIX (SFU) 3.5, set up User Name Mapping so UNIX UIDs line up with Windows accounts, then publish an NFS share with the right permissions. This walkthrough explains how to configure NFS on Windows Server 2003 end to end, fixes the rough spots in the classic install steps, and flags the modern, supported replacement so you do not build on a dead platform by accident.

Important first: Windows Server 2003 reached end of life on 14 July 2015 and SFU 3.5 is unsupported. If this is for a fresh deployment, jump to the modern equivalent at the end and use the built-in Server for NFS role on a current Windows Server. The 2003 procedure below is for legacy environments you still have to keep alive.

What NFS on Windows Server 2003 actually gives you

NFS (Network File System) is the native file-sharing protocol of UNIX and Linux. Out of the box, Windows speaks SMB/CIFS, not NFS. To let UNIX/Linux clients mount a folder hosted on Windows Server 2003 the way they mount any other NFS export, you add the NFS server component that ships inside Services for UNIX 3.5.

Two pieces make this work, and most failed setups trip over the second one:

• Server for NFS — the service that listens for NFS client requests and serves the shared folder.
• User Name Mapping — the translator that matches a UNIX user (identified by a numeric UID/GID) to a Windows account, so file ownership and NTFS permissions are enforced correctly.

Without correct name mapping, a UNIX client either gets permission denied or, worse, lands as an anonymous/nobody user with the wrong access. Getting the mapping right is the heart of how to configure NFS on Windows Server 2003.

Before you start: prerequisites and a plan

• Log in to the Windows Server 2003 box with a local Administrator (or Domain Admin) account.
• Have the SFU 3.5 installer available. The classic English package is SFU35SEL_EN.exe, a self-extracting archive.
• The export folder should live on an NTFS volume — FAT/FAT32 cannot store the ownership and permissions NFS relies on.
• From the UNIX/Linux host you want to integrate with, get copies of /etc/passwd and /etc/group. These supply the UIDs and GIDs you will map.
• Plan for a reboot — the install requires one before the services run cleanly.

Step 1 — Install Services for UNIX 3.5

The installer is a wrapper that first extracts files, then runs the real MSI. Take it in two phases.

1. Double-click SFU35SEL_EN.exe and click Run if prompted by the security warning.
2. When the extraction dialog appears, change the destination to a sensible folder (for example C:\SFU_Install) and click Unzip.
3. After extraction completes, open that folder and double-click sfusetup.msi to launch the actual setup.
4. Click Next through the welcome and user-information screens.
5. Read and accept the license agreement, then click Next.

Choose a Custom installation

The default ("Standard") install does not give you control over the name-mapping component, so pick Custom Installation instead.

1. Select Custom Installation and click Next.
2. In the component tree, make sure Server for NFS is set to install (this is the NFS server itself).
3. Set User Name Mapping to install as well. Leave the other components at their defaults unless you specifically need them.
4. On the mapping/security screen, enable both authentication options offered (Windows-to-UNIX and UNIX-to-Windows mapping support), then click Next.
5. When asked for the Windows domain name used for mapping, set it appropriately for your environment. In the original deployment this was SYSDEV; substitute your own domain or the local computer name. Click Next.
6. Confirm the install path and click Next / Finish to install.
7. Reboot the server when prompted. This is required — the NFS and mapping services start properly only after the restart.

Tip: if you run a single standalone server rather than a domain, you can point User Name Mapping at the local machine name instead of a domain. The mapping logic is the same; only the scope of the Windows accounts changes.

Step 2 — Supply the UNIX identity source

User Name Mapping needs to know which UNIX UIDs and GIDs exist. The simplest, most portable method is to feed it copies of the UNIX password and group files.

1. Create a folder on the Windows server to hold them, for example C:\SFU.
2. Copy /etc/passwd and /etc/group from the UNIX/Linux host into C:\SFU. Transfer them as plain text (use binary mode in your transfer tool to avoid line-ending corruption, or verify the files afterward).

Security note: these files list account names and group memberships. Restrict NTFS permissions on C:\SFU to administrators only. (Modern Linux keeps password hashes in /etc/shadow, not /etc/passwd, so the copied passwd file contains identities and UIDs, not secrets — but treat it carefully regardless.)

Step 3 — Configure User Name Mapping

This is where you tell Windows how a UNIX user becomes a Windows user. Open the management console and wire up the identity sources.

1. Open Start → Programs → Windows Services for UNIX → Services for UNIX Administration.
2. In the left pane, select User Name Mapping.
3. Choose Use Password and Group files (rather than NIS).
4. Enter the paths to the files you copied: C:\SFU\passwd and C:\SFU\group.
5. Click Apply. The console reads the files and learns the UNIX users and groups.

Create the user maps

Now connect specific UNIX users to specific Windows users.

1. Click List Windows Users and List UNIX Users to populate both columns.
2. Add the maps you need. Each map pairs one UNIX user with one Windows user. You can also use simple maps to auto-match accounts that share the same name.
3. For UNIX root (UID 0), do not map it to a Windows administrator. Instead create a dedicated, low-privilege Windows account — in the original setup this was an ID named unixmap — and map UNIX root to that. This keeps a remote root user from inheriting Administrator rights on the Windows box.
4. Click Apply after defining the maps.

Why the unixmap account matters: on UNIX, root is all-powerful. If you mapped root straight to the Windows Administrator, anyone with root on the client could do anything to the share. Mapping root to a constrained account (unixmap) lets you grant exactly the access you intend and nothing more.

Step 4 — Grant NTFS permissions on the folder

NFS access is gated by two permission layers: the NFS share permissions and the underlying NTFS permissions. Both must allow the mapped Windows account, or the client is blocked.

1. Right-click the folder you intend to export and choose Properties.
2. On the Security tab, add the mapped account (for example unixmap) and grant it Read & Write (or the level appropriate to your use).
3. Add any other mapped Windows users that need access and set their NTFS rights too.
4. Click Apply.

If a UNIX client can mount the export but cannot write, the NTFS layer is the usual culprit — the share said yes but the file system said no.

Step 5 — Publish the NFS share

With identity and NTFS permissions in place, expose the folder over NFS.

1. Back in the folder's Properties, open the NFS Sharing tab (added by SFU).
2. Select Share this folder and give it a clear share name — UNIX clients will mount it by this name.
3. Click Permissions.
4. Set Type of access to Read-Write for the clients that should be able to write.
5. Check Allow root access only if those clients legitimately need root-level access to the export (it disables root squashing for them).
6. For tighter control, scope access by client machine or subnet rather than "All Machines".
7. Click OK, then OK again to close Properties.

Common pitfalls when you configure NFS on Windows Server 2003

• Skipping Custom install. The Standard install can omit or hide User Name Mapping. Always pick Custom so you can confirm both Server for NFS and User Name Mapping are selected.
• Mapping root to Administrator. A serious security hole. Use a dedicated limited account such as unixmap.
• Forgetting NTFS permissions. NFS share permission alone is not enough; the mapped Windows account also needs NTFS rights on the folder.
• Sharing from a FAT/FAT32 volume. Ownership and permissions cannot be enforced; host the export on NTFS.
• Stale identity files. If you add UNIX users later, re-copy passwd/group and reapply the mapping, or the new users will not resolve.
• Firewall blocking the ports. NFS uses portmapper/RPC on TCP/UDP 111 plus the NFS service ports. Open these between client and server, or mounts time out.
• No reboot after install. The services do not initialize fully until the post-install restart.

Verification: confirm the NFS export works

Test from the UNIX/Linux client, not just the Windows console.

1. List the exports the server is offering:
   showmount -e <windows_server_ip>
2. Mount the share (create the mount point first):
   mkdir -p /mnt/winnfs
mount -t nfs <windows_server_ip>:/<ShareName> /mnt/winnfs
3. Verify it is mounted:
   mount | grep winnfs  or  df -h /mnt/winnfs
4. Prove read and write:
   touch /mnt/winnfs/nfs_test.txt && ls -l /mnt/winnfs
5. Confirm ownership maps as expected. The file owner should reflect your User Name Mapping configuration, not nobody/4294967294.

On the Windows side, the Services for UNIX Administration console shows active connections, and Event Viewer logs NFS and mapping errors if a mount is rejected.

The modern equivalent (do this for any new build)

SFU was discontinued; its functionality moved into the operating system. On Windows Server 2008 R2 through Windows Server 2022/2025, you do not install a separate package — you add the built-in Server for NFS role service.

• Add the role with PowerShell:
  Install-WindowsFeature FS-NFS-Service -IncludeManagementTools
• Create an NFS share with PowerShell:
  New-NfsShare -Name "Data" -Path "D:\Data" -Permission ReadWrite
• Manage shares and client groups with the NFS-related cmdlets (Get-NfsShare, Set-NfsShare, Grant-NfsSharePermission) or the Server Manager File and Storage Services UI.

Identity mapping is also modernized: instead of standalone User Name Mapping, current Windows Server uses Active Directory identity mapping (with UID/GID attributes) or an unmapped UNIX user access (AUUA) option for simpler scenarios. The concepts you learned above — map UNIX identities to Windows, set both NFS and NTFS permissions, then verify from the client — carry straight over.

Key Takeaways

• To configure NFS on Windows Server 2003 you install Services for UNIX 3.5 and enable both Server for NFS and User Name Mapping.
• Map UNIX identities from copies of /etc/passwd and /etc/group, and map UNIX root to a limited account (e.g. unixmap) — never to Administrator.
• Access depends on two layers: NFS share permissions and NTFS folder permissions; both must allow the mapped account.
• Always verify from the UNIX client with showmount -e and a real mount + read/write test, and open RPC/portmapper port 111.
• Windows Server 2003 and SFU are end of life — for new builds use the built-in Server for NFS role (Install-WindowsFeature FS-NFS-Service) on a supported Windows Server.

Frequently Asked Questions

Do I need Services for UNIX to run NFS on Windows Server 2003?

Yes. Windows Server 2003 does not include an NFS server natively, so you must install Windows Services for UNIX 3.5, which provides the Server for NFS and User Name Mapping components. On Windows Server 2008 R2 and later this capability is built in as a role, so SFU is no longer needed.

Why does my UNIX client get "permission denied" after mounting the share?

Almost always an identity or permissions mismatch. Check that User Name Mapping has loaded your passwd/group files and that the UNIX user is mapped to a Windows account. Then confirm that account has both NFS share permission (Read-Write) and NTFS permission on the folder. If the owner shows as nobody, the mapping is not resolving.

Which network ports do I need to open for Windows NFS?

NFS relies on the RPC portmapper on port 111 (TCP and UDP) plus the NFS service ports. Make sure these are open between the client and the Windows server; a blocked port 111 causes mounts and showmount to hang or time out.

Is it safe to keep running NFS on Windows Server 2003 today?

No, not for anything internet-facing or important. Windows Server 2003 has been unsupported since July 2015 and receives no security patches. Keep legacy 2003 NFS servers isolated on a trusted internal network and plan a migration to the built-in Server for NFS role on a current Windows Server release.

If this guide helped you configure NFS on Windows, subscribe to @explorenystream on YouTube for more practical sysadmin and Windows–UNIX interop walkthroughs.