在復雜的主機與網絡環境中，我們可能會接觸到多種主機與操作系統，配合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=-