NET APP FAS3250挂载目录用户组权限无法正常访问的解决方法

NET APP FAS3250挂载目录用户组权限无法正常访问的解决方法 主题 NET APP FAS3250（A控）挂载目录用户组权限无法正常访问的解决方法 诊断过程与思路

经过多天的排查和诊断，终于找到了故障的原因，具体的分析如下：

一、故障现象

linux用户在拥有组的读写权限时（rwx）时，无法正常的访问FAS3250通过NFS共享出来的目录。

二、诊断思路

1、前面简单的NFS服务启动、客户端挂载权限，参数都一一确认没有问题，故障依旧。

2、对比了深圳、成都其他集中存储控制器关于NFS(由于缺乏整个NFS的工作原理的知识，所以这里只检查了NFS相关的服务，所以导致后面很久都没有找到具体原因)，所有的NFS服务及参数都是一致的，暂时确定没有问题，故障依旧。

3、NFS clinet各版本的系统挂载测试，问题依旧。

4、没有找到原因后，整理一下思路，由于是用户组的权限问题，猜想应该在存储上关于NFS认证和groups相关的选项可能存在问题。通过存储的options nfs选项发现两个选项和nfs的groups有关：

nfs.authsys.extended_groups_ns.eanble on

nfs.max_num_aux_groups 256

根据红帽官网，NFS有AUTH_SYS与RPCSEC_GSS两种。

AUTH_SYS又称AUTH_UNIX，这依赖于客户端声明其用户的UID与GID。这很可能由于恶意或误配置，导致权限控制错误（我们是V3,目前我们存储上是采用的这种方式认证）。

RPCSEC_GSS在NFSv4是强制实现的，使用Kerberos认证。服务器不依赖于客户端来正确地表示哪个用户正在访问文件，而是通过加密学。这种方式是最直接的安全挂载方式，因为一旦配置好Kerberos，不需要其他额外的 *** 作。

我们生产环境就是采用的sys的认证(在我上一篇，FAS 3250的NFS服务的配置上也有说明)，

根据NET APP的官网，nfs.authsys.extended_groups_ns.eanble on针对NFS的sys认证，如果设置为on后，就表示，第17个组可以不用newgrp来切换。nfs.max_num_aux_groups 256 表示最大支持256个组(netapp默认就是32和256)

为什么会有16个组的限制呢？原因如下：

This 16 group limit with auth_sys is not tuneable. It is defined in RFC 5531 and cannot be adjusted or patched

对比这两个参数和其他存储设置一样的，猜想是不是选项没有生效，就通过不停的off/on来测试客户端的状态，最后发现：

nfs.authsys.extended_groups_ns.eanble on时，用户在属主和属组都是rwx的情况下，可以自己创建文件，但是文件的属组是nfsnobody,进入有读写的组权限的目录时，权限拒绝。

nfs.authsys.extended_groups_ns.eanble off时,用户创建文件的属性正常（组权限正常显示），也能正常进入到有读写的组权限的目录，但是超出了16个的组，需要用newgrp来切换。

通过在客户端抓包分析如下（准备抓包，发现有前辈遇到类似的问题，就借用了）：

root肪目前共有20个组，如图所示：

但是抓包只抓到了16个组的信息（没有后续的1018 1019等组信息），如图所示：

关于NFS的认证链接：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/s1-nfs-security

5、经过上面的分析和验证，我们目前能够确认造成我们故障的原因是：由于我们开启了组认证的扩展方式后，NFS server就无法识别到到组的信息和身份（所以组就变成了nfsnobody了），针对nfsnobody，我们是没有给任何权限的，所以就没有办法读写了，但是我们其他存储的控制器都是同样的设置，却没有这个问题，猜测在我们的存储上还有其他的辅助选项设置有问题。

6、在NET APP的官网论坛继续查询发现有一个相关问题的回复：

onTap for having the NFS server ignore the supplemental gids supplied by the client when using SYS_AUTH and instead perform it's own lookup (from NIS/LDAP etc) to determine group membership. This would hugely benefit installations who cannot move to Kerberos auth but still run in to issues with 16 group limitations on NFS

参考链接：https://community.netapp.com/t5/Network-and-Storage-Protocols/RFE-Add-support-for-manage-gids-to-rpc-mountd-in-DataOnTAP/td-p/72448

大概意思：当NET APP开启NFS服务时且认证方式是AUTH_UNIX时，收到客户端的NFS认证请求时，会忽略通过认证传过来的补充的GID信息，然后自己去NIS/LDAP的配置，来确定用户的组ID身份和权限。

看到这里突然就有点顿悟了：前面已经抓包得出来了结果，只要是auth_unix的方式，不管你NFS服务器上如何的设置的，客户端只会发送16个组的信息过来验证，相要获取更多的信息，从NFS client是不可能的，除非从NIS/LDAP服务器获取，是我们没有配置LDAP服务器还是配置有问题？。

7、怀着激动的心，颤抖的手，在存储上通过options ldap相关的配置对比发现，我们其他控制器都有配置LADP的相关信息，就这台没有。配置好LDAP相关的配置：

options ldap.base dc=XXX,dc=XXXX

options ldap.enable on

options ldap.servers XXXXX

(配置到这里，突然又想起来之前杨经理让在LADP接一个存储段的网线，当时还问他LDAP服务器不挂载，不登录，为啥要接到172段里面去，后面也没有细问原因，现在想起来可能就是这个原因了)

找了项目组的同事确认以及我们用iter账号确认，均正常。

三、总结：

遇到问题，还是先要仔细确认我们能够确认有可能会引起故障现象的原因，如果找不到原因，可以尝试再考虑全面一点（网络、架构）就会有一些新的疑问点，这样一来，对整个业务运行又熟悉了一遍了。另外重点说明一下，个人觉得设备和系统的官网提供的信息或者问题比百度出来的信息要准确和有用得多。所以遇到问题可以直接选找官网，将会更有效率。