环境
- CentOS 7.6
问题
RHEL 7.6 服务器作为 NFS 服务器。NFS 共享导出并挂载到 Linux 和 Windows 客户端 (windows 2016) NFS 服务器和 NFS 客户端均加入 AD 域。
NFS Linux 客户端挂载的 NFS 共享可以使用 AD 域帐户进行读写。用于导出的选项是“options=rw,sync,no_root_squash” 但是，在 Windows 中使用默认选项安装相同的 NFS 共享时。我们使用带有可选功能包的 Windows NFS 客户端。使用默认选项，NFS 可以在 Windows 中成功挂载，但任何 AD 用户都没有写权限。为了启用写入权限，我们修改了Windows注册表，并将匿名UID和GID设置为0。重新启动服务并挂载NFS共享后，任何AD用户都可以从AD写入。
现在，当我们回到 NFS Linux 客户端并检查文件所有权时，它显示为 root 用户，而不是编写或创建它的用户。我们尝试更改AD用户的UID和GID的注册表设置，但无法挂载NFS共享。因此，别无选择将其保留为 0。还在 NFS Linux 客户端中启用了 idmapd.conf 文件来测试这是否有帮助，但根本没有任何改变。
有什么方法可以实现这一点 - 从 NFS Windows 客户端在 NFS 共享上写入的文件的所有权与 NFS Linux 客户端中反映的相同，其中两台计算机都是同一 AD 域的一部分？
解决
在 Windows NFS 客户端上测试观察结果：
当用户创建共享时，该文件夹的默认权限属于 root 用户。
因此，如果共享需要由不同的用户读取/写入，则这是不可能的。在 Windows 中，可以使用匿名 UID 和 GID 作为“root”用户，也可以将导出的文件夹权限更改为 AD 中的其他用户/组。
将父文件夹（导出文件夹）的权限更改为 AD 用户和组，使用同一用户从 Windows NFS 客户端挂载该文件夹，所有读/写操作均正常运行。
诊断步骤
“为了进行读/写，我们必须通过添加值 0 的“匿名 UID”和“匿名 GID”来更改一些注册表设置。我们注意到值 0 以外的任何值都不起作用。很可能是因为在 Linux 中我们也使用AD用户，Windows一般不会给出任何UID和GID，Linux也没有要求Windows使用特定的范围，因此我们只能通过Linux来识别UID和GID。 因此，当在 Windows 客户端中挂载 NFS 共享时，它会使用该共享驱动器的 GID 和 UID 作为 0（相当于根）。”
如果服务器使用根 ID (0) 在 Windows 上挂载驱动器，则这可能是整个共享使用的用户（以及在执行任何操作时）。这可以通过获取 tcpdump、在 Windows 上执行一些操作来检查NFS 客户端并查看它使用哪个用户进行 NFS 调用。NFSv3 使用 RPC 数字 ID 来匹配用户，因此如果 Windows 使用此 ID 0，则这看起来像是 WIndows NFS 问题。 在线阅读有关 Windows NFS 选项的信息，似乎 Windows NFS 客户端不支持 4.1 (https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview)，这会使事情变得容易一些，因为用户是通过字符串而不是 NFS3 中的数字 ID 来标识的。
继续上网查找，找到了这个非常详细的文档（https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/NFS-Identity-Mapping-in-Windows-Server-2012/ba-p/424602） 关于 NFS 映射（显然 Windows 和 UNIX 用户之间的一些映射是必要的）：
正如该文件所述：“身份映射机制为了使用 NFS 请求中使用的 UID 和 GID 值，需要将它们转换或映射为底层 Windows 平台可以使用的标识。 Microsoft NFS 服务器和 NFS 客户端提供了多个选项来映射 NFS 请求中的身份，每个选项都有一系列优点和缺点”
据此，如果两台机器都是 AD 的一部分，则它们只需要启用 AD 映射即可工作。
网友评论