使用NFS4協議在NETAPP儲存下不能MOUNT的分析和解決

之前的NETAPP儲存一直使用的是預設的MOUNT協議，也就是NFS3的協議，因為一個應用需要使用NFS4的協議，於是開始了苦難之旅。

首先預設情況下NFS4協議在NETAPP儲存上是沒有開啟的，這個開啟很容易，基於WEB的圖形介面沒有配置的地方的，只能透過命令列進行配置。登入進 去，然後使用options nfs.v4.enable on命令開啟NFS4協議，這時候會提示說在冗餘機頭的情況下，那邊機頭也要搞，否則發生FAILOVER的時候那邊就不能提供NFS4服務了，於是把兩 邊都搞好，在VOL上劃了個QTREE，把QTREE EXPORT出去，然後就開始在客戶端折騰。[@more@]

首先是客戶端MOUNT不上去，報錯如下：
Warning: rpc.idmapd appears not to be running.
All uids will be mapped to the nobody uid.
mount: block device 192.168.1.1:/vol/vol1/xxx is write-protected, mounting read-only
Warning: rpc.idmapd appears not to be running.
All uids will be mapped to the nobody uid.
mount: cannot mount block device 192.168.1.1:/vol/vol1/xxx read-only

WARNING很容易理解，說IDMAPD服務沒起，所以所有的UID對映過來都會被對映成NOBODY的UID，這個只要啟了IDMAPD服務就好了，使用service rpcidmapd start命令去啟。但後面的就很難理解了，為什麼會說是防寫的，然後要被MOUNT稱只讀的，然後即使是隻讀的也MOUNT不上去呢？關鍵最難以理解的是為什麼明明是MOUNT一個NFS的裝置，提示確實說BLOCK DEVICE不能被MOUNT，為什麼就成了BLOCK DEVICE呢？
GOOGLE+BAIDU+NOW.NETAPP.COM+REDHAT.COM搜尋了半天，沒有什麼進展。換個機器試試吧，因為這個機器不是自己安裝的，不確定是否缺什麼包啥的。於是換了個機器，暫且叫新機器（之前的機器就叫老機器），雖然還是報IDMAPD的報警，但是結果確實MOUNT上去了，暈了，看來是老機器有問題。

也正是這個很巧合能MOUNT的問題，導致了後面一路的誤判，尋找問題中出現了方向性錯誤，浪費了很多的時間。

開始把兩邊的後臺服務搞成一樣，不行；比較OS版本，一致；比較網路訪問許可權，沒問題，因為測試中老機器使用NFS3協議能順利MOUNT；折騰了半天實在沒轍，所有招數都用盡了，突然想起來了STRACE。先做個STRACE看看整個MOUNT過程中到底幹了些什麼，卡在哪一步出現的錯誤吧。

做了STRACE後發現最後錯誤的地方在：
mount("192.168.1.1:/vol/vol1/xxx", "/u09", "nfs4", MS_MGC_VAL, "1") = -1 EACCES (Permission denied)
也就是會有一個許可權的錯誤，這又是一個誤導我的地方。因為NFS3能MOUNT，MOUNT上去後能讀寫，那說明不應該出現許可權相關的問題啊。拿著新老機器的STRACE去做對比，新的機器在這一步的返回結果如下：
mount("192.168.1.1:/vol/vol1/xxx", "/u09", "nfs4", MS_MGC_VAL, "1") = 0
看來問題就是出在這裡了，而且相同版本的OS，相同版本的NFS相關的包，一個可以一個不可以，那隻能看看是否是BUG了。還別說，真的還就找到了一個BUG，在REDHAT的官網上，BUGID=197504（nfs4 AUTH_GSSAPI server returning EACCESS on all mount attempts ），裡面說在nfs-utils-1.0.9-3版本中修復了這個BUG，雖然BUG發生的版本跟我使用的版本不一致，這個BUG描述的是出現在nfs-utils-1.0.8-2，而我使用的版本是nfs-utils-1.0.6，但很多時候ORACLE就經常這麼幹，只是說新的版本中發現並驗證了這個問題，並不代表老的版本一定沒有這個問題，很可能這個問題一直就有，只不過在某個版本中被發現了。

於是下載了0.9的版本，結果很悲劇，裝不上。這個版本很新，所以依賴的東西太多，而且很多是很底層的東西，看來想裝上去是不行了，但是這個BUG裡描述了一個PATCH的解決辦法，只要改一段原始碼，然後重新編譯下就好了，看起來挺可行的。因為BUG出現在0.8，不確定我使用的0.6中程式碼是否一致以及估計我連CTRL+C然後CTRL+V都找不到地方，所以下了0.8的，結果編譯的時候還是報一堆的依賴關係沒有，這下絕望了。


既然這條路不通，那試試新的版本吧，有裝好的5.4的REDHAT，這個上面的NFS版本很新，結果測試了居然也不行，跟老機器報的錯一模一樣，接連試了幾個機器，都不行，這就見鬼了，為什麼只有新機器可以，所有其他機器都不行呢，但也是在找不出新機器跟其他機器之間的不同在哪裡。

在絕望的時候，希望終於來了，在NOW.NETAPP.COM上找到了Solution ID: kb13800 的一個文章，裡面描述到：
With NFSv4, client "mount" requests proceed with LOOKUP sequences to parse names from the root. As a result, if a parent directory is exported such that name lookup is blocked to a child, then the mount will fail.

踏破鐵鞋無覓處，得來全不費功夫啊，到儲存上一看，新機器以前為了做測試，直接加過/VOL/VOL1級別的讀寫許可權，所以去MOUNT它下面的QTREE就符合上面的條件，所以也只有它能MOUNT的上去，其他所有人都MOUNT不上去。之前一個簡單的測試，竟然給問題的解決帶來這麼多的誤導，無語啊。


找到了原因，問題解決就簡單多了，只要把需要訪問的機器全部把QTREE的上級目錄的讀許可權加上就全部OK了