Windows Server 2008 R2 添加且制成“NFS服务器”角色后与Unix客户端匿名访问常见问题

在复杂的主机与网络环境中，咱们可能会接触到多种主机与操做系统，配合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:\testaa

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=-