在复杂的主机与网络环境中，我们可能会接触到多种主机与操作系统，配合Windows Server 2008 R2的原生“NFS服务器”功能可以让这样的复杂操作系统更方便应用。
然而面对网络上众多的帮助指南和设置向导难免会造成一些操作不够全面，本博文进行相关尝试后对其中的匿名访问的少支持进行一些弥补，同时也欢迎诸多网友的指正。
微软官方网站上提供相应NFS服务器配置指南，如果您是初次使用可以参考这个链接：http://technet.microsoft.com/zh-cn/library/cc753312.aspx
本文涉及到的Unix客户端匿名访问Windows提供的NFS服务器属于较特殊方向，因此如果在没有较为安全的防护措施下还是非常建议您使用有身份验证授权的方式进行访问与连接；同时现有环境并没有使用域控进行统一授权与管理，因此操作中完全是按照独立主机的模式进行实践的。
以下内容是本人在亲自使用后总结的允许匿名访问后的常见问题。
问题一：Unix客户端进行挂载（mount）的时候出现 “Input/output error”是什么情况？
解答：客户端需要开启Protmap服务；同时服务端需要设置好相应的NFS访问权限（匿名访问权限需要设置GID=-2，UID=-2），安全策略中设置“网络访问: 将 Everyone 权限应用于匿名用户”为“已启用”，以及NFS权限对共享目录进行读写操作。
|
|
|
|
Figure 1问题一图示，设置NFS身份验证，确保匿名访问有效 |
Figure 2问题一图示，设置NFS权限，确保共享目录的可读写 |
问题二：客户端挂载后提示没有权限（“Permission Denied”）创建文件或文件夹
解答：这里面提到的没有权限多数是因为在NFTS的权限策略无法创建，因为使用的是Windows下本身不存在的Unix匿名账户ID=-2的这个“用户”，我们需要将这个特殊的用户ID添加到对应的NTFS访问控制权限（ACL）里面，这里面我们借助nfsfile命令（该命令需要在NFS服务角色安装好之后方可使用）来完成。
帮助命令很简单，下表展示内容即为帮助文件信息：
|
操作 NFS 文件的服务属性。 NFSFILE [/v] [/s] [/i[[u=<uid>]|[g=<gid>]|[wu=<account>]|[wg=<account>]]] [/r[[u=<uid>]|[g=<gid>]|[m=<mode>]]] [/c[w|x]] <filespec> /? - 此消息 /v - 详细 /s - 扫描子目录查找匹配的文件 /i - 包括与指定标准相匹配的文件 u <uid> - NFS 所有者 SID 匹配<uid> g <gid> - NFS 组 SID 匹配<gid> wu <account> - NFS 所有者 SID 匹配<account> wg <account> - NFS 组 SID 匹配<account> /r - 替换文件上指定的选项 u <uid> - 设置 uid g <gid> - 设置 gid m <mode> - 将模式位设置为<mode> wu <account> - 设置 Windows 所有者帐户 wg <account> - 设置 Windows 组帐户 /c - 转换文件依据 w - Windows 样式 ACL (已映射) x - Unix 样式 ACL (未映射) |
实例：
|
nfsfile /v /ru=-2 /rg=-2 /s /cx e: estaa |
Figure 3添加匿名用户（组）-2进入共享文件夹
此时在通过客户端Unix访问这个共享目录，即可创建文件（夹）了。
问题三：如果遇到通过手工自行修改过ACL的文件夹，在设置了NFS共享后无法在客户端创建文件夹该如何操作？
回答：首先通过问题一与问题二进行一下设置，一般来说只要设置好了NFTS的权限与NFS的权限就可以进行客户端的访问与写入操作了。但是如果有一个要设置NFS共享的文件夹之前被做过多次的ACL的设置导致了ACL的权限出现的错乱，使得共享之后无法创建相应的文件夹与文件，此时有两种比较好的方法：
方法一：在这个已经进行了NFS共享的文件夹下创建一个子文件夹，并且使用nfsfile设置相应的权限映射，以后对这个子文件夹进行操作即可。
方法二：停止之前的NFS共享，创建一个新的文件夹并设置好NFS权限，最后按照问题二中的操作使用nfsfile进行全新设置，然后将原始的文件夹下的内容拷贝（剪切）到新文件夹下即可解决。
问题四：这种映射的原理是什么？
回答：先看一下nfsfile设置好映射权限后的文件夹acl属性
Figure 4左侧是Windows下的文件夹所有者，右侧的显示是Mount到Unix客户端之后的这个文件夹的所有者
可以很清楚的看到相应的-2用户组对应的Unix编号为4294967294（-2转换为32位二进制后再转换成十进制后的呈现），而这样的ACL在Windows 的表现是什么样的？
Figure 5通过PowerShell的Get-Acl命令捕获到的访问列表，因为我并没有设MODE SID，所以上面显示阻止了所有控制权；Owner与Group ID均为4294967294，且有可读权限，Owner同时还具有全部控制权限；Other ID允许读的权限
Figure 6这是一张微绘制的UNIX客户端用户信息与NTFS下ACL信息的对应图
Figure 7 Linux下面的User和UserID的对应关系，其中nfsnobody对应的UserID=65534，他的目的是用作匿名（Anonymous）共享
同样的在一些商用存储中对于这个匿名映射使用的也是-2来实现的，只不过由于使用的字节长度不同，所表现出来的数值是不一样的。
Figure 8一款NatApp的NAS提供的匿名共享所映射过去的匿名用户是UID=65534，实际上是另一种-2（16位带符号运算）
|
Figure 9 16位带符号的-2 |
Figure 10十进制的-2 |
Figure 11 32位带符号的-2 |
附录：
关于4294967294 用户可以参考MSDN的文章，Who's 4294967294? http://blogs.msdn.com/b/sfu/archive/2007/04/19/who-s-4294967294.aspx
NFS_Account_Mapping_in_Windows_Server_2008_R2.doc 的下载地址 http://download.microsoft.com/download/F/5/0/F5062BD4-4B9D-4D00-ACB6-D94D2E2DABEA/NFS_Account_Mapping_in_Windows_Server_2008_R2.docx
-=EOB=-