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