Windows并不是只能通过SMB协议提供文件共享，Server版本中的Server for NFS角色可以把NTFS目录直接导出为NFS挂载点。无论是Linux应用服务器、容器节点还是虚拟化宿主机，只要网络可达，就能像挂载普通NFS存储一样访问Windows上的文件。本文以Windows Server 2022为环境，从角色安装、共享创建、权限设置到Linux客户端挂载做一次完整演示。
一、安装Server for NFS角色
首先要明确一点：Windows 10和Windows 11家庭版、专业版通常只提供NFS客户端功能，不能原生作为NFS服务器使用。真正需要把Windows当作NFS服务端的场景，应该选择Windows Server 2016、2019或2022。服务器角色名称是Server for NFS，它位于文件和存储服务下面的文件和iSCSI服务分支中。
安装时打开服务器管理器，点击添加角色和功能，在选择服务器角色页面依次展开文件和存储服务、文件和iSCSI服务，然后勾选Server for NFS。如果系统提示需要额外的功能，直接点击添加功能即可。安装过程不需要重启系统，但建议安装完成后先重启一次PowerShell会话或重新打开服务器管理器，确保管理命令可以正常加载。安装后，可以在服务控制台看到Server for NFS相关服务处于运行状态。
如果习惯使用命令行，也可以用PowerShell一步完成安装。执行下面的命令后，可以用Get-WindowsFeature FS-NFS-Service查看状态，当结果显示Installed就说明角色已经可用。
Install-WindowsFeature FS-NFS-Service -IncludeManagementTools Get-WindowsFeature FS-NFS-Service
安装完成后，Windows防火墙不会自动放行NFS所需端口，后续挂载前需要单独配置入站规则。此外，Server for NFS默认支持NFSv3，较新版本也支持NFSv4.1，但实际是否能协商到v4取决于客户端和服务端设置。
二、创建NFS共享并配置权限
先在Windows服务器上准备一个目录，例如C:\NFSShare。这个目录的NTFS权限会直接影响NFS访问结果，建议先给目标用户或组分配适当的NTFS权限。然后可以通过服务器管理器中的文件和存储服务、共享、新建共享来创建NFS共享，选择NFS共享-快速，按向导指定路径、共享名称和身份验证方式。
身份验证方式直接影响Linux客户端挂载时的行为。Sys模式使用AUTH_SYS，不验证身份，只依赖客户端IP和匿名映射；Krb5系列则需要与Active Directory域环境配合，安全性更高，但配置也更复杂。对于内部测试或单向访问环境，Sys模式通常足够。下面的PowerShell命令创建了一个名为NFSShare的共享，启用未映射用户访问，并允许root访问。
New-NfsShare -Name "NFSShare" -Path "C:\NFSShare" -Authentication Sys -EnableUnmappedUser $true -AllowRootAccess $true
创建共享后，还需要给具体主机或网段授权。NFS权限与SMB权限不太一样，它基于客户端IP地址或主机名来控制，权限级别分为只读、读写和无权限。执行下面的命令可以允许192.168.1.0/24网段内的主机读写该共享，同时允许root权限。注意，如果NTFS权限只给了读取，那么即使NFS授权为读写，最终也只能读取，因为Windows会取NFS与NTFS权限的交集。
Grant-NfsSharePermission -Name "NFSShare" -ClientName "192.168.1.0/24" -Permission ReadWrite -AllowRootAccess $true Get-NfsShare Get-NfsSharePermission -Name "NFSShare"
如果希望只让某一台Linux服务器访问，可以将-ClientName改成具体IP地址，例如192.168.1.50。修改权限后无需重启NFS服务，新的挂载会立即生效，已经建立的挂载可能需要重新挂载才能完全应用新权限。
三、放行防火墙并完成Linux挂载
Windows防火墙默认会拦截NFS相关流量，因此在正式开始挂载前需要放行端口。NFS服务主要使用2049端口，同时依赖端口映射器111端口和mountd服务20048端口。如果这些端口不通，Linux客户端执行showmount -e时会报RPC超时或程序未注册错误。下面的PowerShell命令创建三条入站规则，允许TCP和UDP流量。
New-NetFirewallRule -DisplayName "NFS 2049" -Direction Inbound -Protocol TCP -LocalPort 2049 -Action Allow New-NetFirewallRule -DisplayName "NFS Portmap 111" -Direction Inbound -Protocol TCP -LocalPort 111 -Action Allow New-NetFirewallRule -DisplayName "NFS Mountd 20048" -Direction Inbound -Protocol TCP -LocalPort 20048 -Action Allow
如果还启用了NFSv4或使用Kerberos身份验证，可能还需要放行UDP 2049以及Kerberos的88端口。实际环境中建议先只对需要访问的网段开放，避免将NFS端口暴露到公网。
Linux客户端方面，以Ubuntu为例，先安装NFS客户端组件，然后使用showmount命令查看Windows服务器导出的共享列表。如果能看到/NFSShare，说明服务端端口和NFS服务状态基本正常。
sudo apt update sudo apt install nfs-common -y showmount -e 192.168.1.100
接下来创建挂载点并执行挂载。挂载命令中的服务器地址需要替换为实际Windows Server IP，共享名要与创建时一致。挂载成功后可以使用df -h查看容量信息，也可以直接写入文件进行读写测试。
sudo mkdir /mnt/nfs sudo mount -t nfs 192.168.1.100:/NFSShare /mnt/nfs df -h /mnt/nfs sudo touch /mnt/nfs/test.txt ls -l /mnt/nfs
如果挂载失败并提示权限不足，需要回到服务端检查NFS共享权限、NTFS目录权限以及未映射用户设置。NFS共享默认不允许root用户访问，除非显式设置AllowRootAccess为true，否则root写入时会变成匿名用户并受到权限限制。这一点在容器或虚拟机场景中尤其容易踩坑。
四、处理匿名映射与安全加固
使用Sys身份验证时，Windows会把无法映射到本地账户的访问者当作匿名用户处理。匿名用户默认对应的UID和GID通常是-2，这可能导致Linux端显示文件属主为nobody或权限异常。此时可以在共享属性中开启未映射用户访问，并为匿名访问指定一个本地用户或UID，让写入操作落到明确的账户上。实际生产环境中，更推荐的做法是将NFS共享与AD DS结合，使用Kerberos v5进行身份验证。
对于不需要Kerberos的小型环境，至少要限制客户端来源。例如只允许192.168.1.0/24网段访问，可以通过NFS共享权限中的主机列表来实现，也可以结合防火墙的-RemoteAddress参数进一步收紧。下面的命令只允许指定网段访问2049端口，其他来源的请求会被直接丢弃。
New-NetFirewallRule -DisplayName "NFS 2049 Restricted" -Direction Inbound -Protocol TCP -LocalPort 2049 -RemoteAddress 192.168.1.0/24 -Action Allow
另外还要留意NTFS和NFS双层权限叠加的问题。很多故障并不是NFS配置错误，而是NTFS目录本身没有给对应用户写入权限。排障时可以先在Windows本地以目标用户身份访问C:\NFSShare，确认NTFS权限正常后，再排查NFS授权和防火墙。只要把端口、共享权限、NTFS权限、匿名映射这四类配置对齐，Windows NFS服务器的稳定性完全能满足常规跨平台文件共享需求。
Windows NFS配置NFS服务器Windows Server修改时间：2026-09-25 03:16:48