使用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了

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-1037484/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25016/viewspace-1037484/