Skip to main content
NetApp Solutions
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

NFS

贡献者
PDF

NFS是一种分布式文件系统协议、它是在Request for Comments (RFC)中定义的开放式IETF标准、允许任何人实施该协议。

通过导出一个可供一个或一组客户端访问的路径、可将Google Cloud NetApp卷中的卷共享给NFS客户端。挂载这些导出的权限由导出策略和规则定义、这些策略和规则可由Google Cloud NetApp卷管理员进行配置。

NetApp NFS实施被视为该协议的黄金标准、用于无数企业级NAS环境。以下各节介绍了Google Cloud NetApp卷中提供的NFS和特定安全功能及其实施方式。

默认本地UNIX用户和组

Google Cloud NetApp卷包含多个默认UNIX用户和组、用于实现各种基本功能。当前无法修改或删除这些用户和组。当前无法将新的本地用户和组添加到Google Cloud NetApp卷。默认用户和组以外的UNIX用户和组需要由外部LDAP名称服务提供。

下表显示了默认用户和组及其对应的数字ID。NetApp建议不要在LDAP中或在重新使用这些数字ID的本地客户端上创建新用户或组。

默认用户：数字ID 默认组：数值ID

  • 根：0

  • pcuser：65534

  • nobody：65535

  • 根：0

  • 守护进程：1.

  • pcuser：65534

  • nobody：65535
备注 使用NFSv4.1时、root用户在NFS客户端上运行目录列出命令时可能会显示为nobody。这是因为客户端的ID域映射配置。请参见名为的部分 NFSv4.1和nobody用户/组 有关此问题描述 以及如何解决此问题的详细信息、请参见。

root用户

在Linux中、root帐户可以访问基于Linux的文件系统中的所有命令、文件和文件夹。由于此帐户的强大功能、安全最佳实践通常要求以某种方式禁用或限制root用户。在NFS导出中、可以通过导出策略和规则以及称为root用户强制转换的概念在Google Cloud NetApp卷中控制root用户对文件和文件夹的控制能力。

root用户强制转换可确保访问NFS挂载的root用户强制转换为匿名数字用户6554 (请参见""一节)、并且当前仅在使用NetApp Volume-Performance时可用、方法是在创建导出策略规则期间为root匿名用户访问选择off。如果root用户强制转换为匿名用户、则该用户将无法再对NFS挂载中的文件或文件夹运行chown或 "setuid/setgid命令(粘滞位)"、而root用户创建的文件或文件夹将anon UID显示为所有者/组。此外、root用户无法修改NFSv4 ACL。但是、root用户仍可访问其没有显式权限的chmod和已删除的文件。如果要限制对root用户的文件和文件夹权限的访问，请考虑使用具有NTFS ACL的卷，创建名为的Windows用户， `root`并将所需权限应用于文件或文件夹。

匿名用户

匿名(anon)用户ID指定映射到未使用有效NFS凭据的客户端请求的UNIX用户ID或用户名。使用root用户强制转换时、这可能包括root用户。Google Cloud NetApp卷中的anon用户为6554。

在Linux环境中、此UID通常与用户名或 nfsnobody`关联 `nobody。Google Cloud NetApp卷还使用6554作为本地UNIX用户` pcuser`(请参见""一节默认本地UNIX用户和组)、如果在LDAP中找不到有效匹配的UNIX用户、则该用户也是Windows到UNIX名称映射的默认回退用户。

由于UID 6554的Linux和Google Cloud NetApp Volumes中的用户名存在差异、因此使用NFSv4.1时、映射到6554的用户的名称字符串可能不匹配。因此、您可能会在某些文件和文件夹上看到 `nobody`用户身份。有关此问题以及如何解决此问题的信息、请参见""一节NFSv4.1和nobody用户/组。

访问控制/导出

NFS挂载的初始导出/共享访问通过导出策略中包含的基于主机的导出策略规则进行控制。定义了主机IP、主机名、子网、网络组或域、以允许访问挂载NFS共享以及主机允许的访问级别。导出策略规则配置选项取决于Google Cloud NetApp卷级别。

对于NetApp Volume-SW、以下选项可用于导出策略配置：

  • 客户端匹配。 IP地址列表以逗号分隔、主机名、子网、网络组和域名列表以逗号分隔。

  • *RO/RW访问规则。*选择读/写或只读以控制对导出的访问级别。NetApp卷性能提供以下选项：

  • 客户端匹配。 IP地址列表以逗号分隔、主机名、子网、网络组和域名列表以逗号分隔。

  • * RO或RW访问规则。*选择读/写或只读以控制导出的访问级别。

  • *根访问(开/关)。*配置根强制转换(请参见一节root用户"了解详细信息)。

  • *协议类型。*此操作会将对NFS挂载的访问限制为特定协议版本。为卷同时指定NFSv3和NFSv4.1时、请将这两个字段留空或同时选中这两个框。

  • * Kerberos安全级别(选择启用Kerberos时)。*提供了krb5、krb5i和/或krb5p选项、用于只读或读写访问。

更改所有权(chown)和更改组(chgrp)

Google Cloud NetApp卷上的NFS仅允许root用户对文件和文件夹运行chown或chgrp。其他用户会看到 `Operation not permitted`错误、即使是在他们拥有的文件上也是如此。如果您使用root用户强制转换(如""一节所述)、则root用户将被强制转换为非rootroot用户用户、并且不允许访问chown和chgrp。目前、Google Cloud NetApp卷中没有允许非root用户使用chown和chgrp的解决方法。如果需要更改所有权、请考虑使用双协议卷并将安全模式设置为NTFS、以便从Windows端控制权限。

权限管理

Google Cloud NetApp卷支持两种模式位(例如rwx的644、777等)和NFSv4.1 ACL、以控制使用UNIX安全模式的卷在NFS客户端上的权限。标准权限管理用于这些对象(例如chmod、chown或nfs4_setfacl)、并可用于支持这些对象的任何Linux客户端。

此外、使用设置为NTFS的双协议卷时、NFS客户端可以利用Google Cloud NetApp卷名称到Windows用户的映射、然后使用该映射解析NTFS权限。这需要通过LDAP连接到Google Cloud NetApp卷、以便提供数字ID到用户名的转换、因为Google Cloud NetApp卷需要有效的UNIX用户名才能正确映射到Windows用户名。

为NFSv3提供粒度ACL

模式位权限仅涵盖语义中的所有者、组和其他所有人、这意味着基本NFSv3没有粒度用户访问控制。Google Cloud NetApp卷不支持POSIX ACL或扩展属性(如chattr)、因此只有在以下情况下才可以使用NFSv3使用精细ACL：

  • 具有有效UNIX到Windows用户映射的NTFS安全模式卷(需要CIFS服务器)。

  • 使用挂载NFSv4.1的管理客户端应用NFSv4.1 ACL以应用ACL。

这两种方法都需要LDAP连接才能进行UNIX身份管理，并需要填充有效的UNIX用户和组信息(请参见一节""LDAP"")，并且只能用于NetApp Volume-Performance实例。要对NFS使用NTFS安全模式卷、必须使用双协议(SMB和NFSv3)或双协议(SMB和NFSv4.1)、即使未建立SMB连接也是如此。要在NFSv3挂载中使用NFSv4.1 ACL、必须选择 `Both (NFSv3/NFSv4.1)`作为协议类型。

常规UNIX模式位提供的权限粒度级别与NTFS或NFSv4.x ACL提供的权限级别不同。下表对NFSv3模式位和NFSv4.1 ACL之间的权限粒度进行了比较。有关NFSv4.1 ACL的信息、请参见 "NFS4_ACL—NFSv4访问控制列表"。

NFSv3 模式位 NFSv4.1 ACL

  • 执行时设置用户ID

  • 执行时设置组ID

  • 保存交换的文本(未在POSIX中定义)

  • 所有者的读取权限

  • 所有者的写入权限

  • 对文件执行所有者权限；或者在目录中查找(搜索)所有者权限

  • 组的读取权限

  • 组的写入权限

  • 对文件中的组执行权限；或者在目录中查找(搜索)组权限

  • 其他人的读取权限

  • 其他人的写入权限

  • 对其他人对文件执行权限；或者在目录中查找(搜索)其他人的权限

访问控制条目(ACE)类型(允许/拒绝/审核)*继承标志*目录继承*文件继承*无传播-继承*仅继承

权限*读取数据(文件)/列表目录(目录)*写入数据(文件)/创建文件(目录)*附加数据(文件)/创建子目录(目录)*执行(文件)/更改目录(目录)*删除*删除子目录*读取属性*写入属性*读取命名属性*写入ACL *写入所有者*写入ACL *写入操作

最后、根据RPC数据包限制、对于AUTH_SYS、NFS组成员资格(在NFSv3和NFSv4.x中)限制为默认最大16个。NFS Kerberos最多可提供32个组、NFSv4 ACL可通过粒度用户和组ACL (每个ACE最多1024个条目)来消除此限制。

此外、Google Cloud NetApp卷还提供了扩展的组支持、可将支持的最大组数扩展到32个。这需要通过LDAP连接到包含有效UNIX用户和组身份的LDAP服务器。有关配置此功能的详细信息、请参见 "创建和管理NFS卷"Google文档中的。

NFSv3用户和组ID

NFSv3用户和组ID以数字ID而非名称的形式通过网线传输。对于NFSv3、Google Cloud NetApp卷不会对这些数字ID进行用户名解析、而UNIX安全模式卷仅使用模式位。如果存在NFSv4.1 ACL、则需要进行数字ID查找和/或名称字符串查找才能正确解析此ACL、即使使用NFSv3也是如此。对于NTFS安全模式卷、Google Cloud NetApp卷必须将数字ID解析为有效的UNIX用户、然后映射到有效的Windows用户、才能协商访问权限。

NFSv3用户和组ID的安全限制

使用NFSv3时、客户端和服务器无需确认尝试使用数字ID进行读写的用户是否为有效用户；这只是隐式信任。这样、只需欺骗任何数字ID即可使文件系统不受潜在漏洞的影响。为了防止出现此类安全漏洞、Google Cloud NetApp卷提供了一些选项。

  • 实施适用于NFS的Kerberos会强制用户使用用户名和密码或keytab文件进行身份验证、以获取Kerberos票证以允许访问挂载。Kerberos适用于NetApp卷性能实例、而仅适用于NFSv4.1。

  • 在导出策略规则中限制主机列表会限制NFSv3客户端对Google Cloud NetApp卷的访问权限。

  • 使用双协议卷并对卷应用NTFS ACL会强制NFSv3客户端将数字ID解析为有效的UNIX用户名、以便正确进行身份验证以访问挂载。这需要启用LDAP并配置UNIX用户和组身份。

  • 将root用户强制转换会限制root用户对NFS挂载可能造成的损害、但不会完全消除风险。有关详细信息、请参见"root用户。 "

最终、NFS安全性仅限于您所使用的协议版本。虽然NFSv3的总体性能优于NFSv4.1、但提供的安全性级别不同。

NFSv4.1

与NFSv3相比、NFSv4.1的安全性和可靠性更高、原因如下：

  • 通过基于租赁的机制实现集成锁定

  • 有状态会话

  • 通过单个端口提供所有NFS功能(2049)

  • 仅限TCP

  • ID域映射

  • Kerberos集成(NFSv3可以使用Kerberos、但只能用于NFS、而不能用于辅助协议、例如NLM)

NFSv4.1依赖关系

由于NFSv4.1中的额外安全功能、因此、使用NFSv3时不需要涉及一些外部依赖关系(类似于SMB需要依赖关系的方式、例如Active Directory)。

NFSv4.1 ACL

Google Cloud NetApp卷支持NFSv4.x ACL、与常规POSIX模式权限相比、它具有明显优势、例如：

  • 精细控制用户对文件和目录的访问

  • 提高 NFS 安全性

  • 改进了与CIFS/SMB的互操作性

  • 取消了使用AUTH_SYS安全性时每个用户16个组的NFS限制

  • ACL无需解析组ID (GID)、从而有效地消除了GID限制NFSv4.1 ACL是从NFS客户端控制的、而不是从Google Cloud NetApp卷控制的。要使用NFSv4.1 ACL、请确保您的客户端软件版本支持这些ACL、并安装了正确的NFS实用程序。

NFSv4.1 ACL与SMB客户端之间的兼容性

NFSv4 ACL与Windows文件级ACL (NTFS ACL)不同、但具有类似的功能。但是、在多协议NAS环境中、如果存在NFSv4.1 ACL、而您使用的是双协议访问(同一数据集中的NFS和SMB)、则使用SMB2.0及更高版本的客户端将无法通过Windows安全选项卡查看或管理ACL。

NFSv4.1 ACL的工作原理

定义了以下术语以供参考：

  • *访问控制列表(ACL)。*权限条目的列表。

  • *访问控制条目(ACE)。*列表中的一个权限条目。

如果客户端在SETATTR操作期间为某个文件设置了NFSv4.1 ACL、则Google Cloud NetApp卷会在该对象上设置该ACL、以替换任何现有ACL。如果文件没有ACL、则文件的模式权限将通过所有者@、组@和所有人@计算得出。如果文件上存在任何现有的SUID/SGID/粘滞位、它们不会受到影响。

当客户端在getattr操作期间获取某个文件的NFSv4.1 ACL时、Google Cloud NetApp卷将读取与该对象关联的NFSv4.1 ACL、构建一个ACL列表并将该列表返回给客户端。如果文件具有NT ACL或模式位、则会使用模式位构建ACL并将其返回给客户端。

如果ACL中存在拒绝ACE、则拒绝访问；如果存在允许ACE、则授予访问权限。但是、如果ACL中不存在任何ACE、则访问也会被拒绝。

安全描述符由一个安全ACL (SACL)和一个随机ACL (DACL)组成。如果NFSv4.1与CIFS/SMB互操作、则DACL将与NFSv4和CIFS进行一对一映射。DACL由ALLOW ACE和DENY ACE组成。

如果在设置了NFSv4.1 ACL的文件或文件夹上运行基本的`chmod`、则会保留现有用户和组ACL、但会修改默认所有者@、组@、每个人@ ACL。

使用NFSv4.1 ACL的客户端可以为系统上的文件和目录设置和查看ACL。在具有ACL的目录中创建新文件或子目录时、该对象将继承ACL中已标记为相应的所有ACE "继承标志"。

如果文件或目录具有NFSv4.1 ACL、则无论使用哪个协议访问文件或目录、都可以使用该ACL来控制访问。

只要父目录上的NFSv4 ACL为ACE添加了正确的继承标志、文件和目录就会继承这些ACE (可能需要进行适当修改)。

在根据NFSv4请求创建文件或目录时、生成的文件或目录上的ACL取决于文件创建请求是包含ACL还是仅包含标准UNIX文件访问权限。ACL还取决于父目录是否具有ACL。

  • 如果请求包含 ACL ，则会使用该 ACL 。

  • 如果此请求仅包含标准 UNIX 文件访问权限，并且父目录没有 ACL ，则会使用客户端文件模式设置标准 UNIX 文件访问权限。

  • 如果此请求仅包含标准UNIX文件访问权限、并且父目录具有不可继承的ACL、则会根据传递给此请求的模式位为新对象设置默认ACL。

  • 如果此请求仅包含标准 UNIX 文件访问权限，但父目录具有 ACL ，则只要父目录的 ACL 中的 ACE 已使用适当的继承标志进行标记，新文件或目录就会继承这些 ACE 。

ACE权限

NFSv4.1 ACL权限使用一系列大小写字母值(例如`rxtncy`)来控制访问。有关这些字母值的详细信息、请参见 "如何：使用NFSv4 ACL"。

具有umask和ACL继承的NFSv4.1 ACL行为

"NFSv4 ACL可提供ACL继承功能"。ACL继承是指在设置了NFSv4.1 ACL的对象下创建的文件或文件夹可以根据的配置继承ACL "ACL继承标志"。

"umask"用于控制在不需要管理员交互的情况下在目录中创建文件和文件夹的权限级别。默认情况下、Google Cloud NetApp卷允许umask覆盖继承的ACL、这是中的预期行为 "RFC 5661"。

ACL格式化

NFSv4.1 ACL采用特定格式。以下示例是对文件设置的ACE：

A::ldapuser@domain.netapp.com:rwatTnNcCy

上述示例遵循以下ACL格式准则：

type:flags:principal:permissions

类型`a`表示"允许"。 在这种情况下、不会设置继承标志、因为主体不是组、并且不包括继承。此外、由于ACE不是审核条目、因此无需设置审核标志。有关NFSv4.1 ACL的详细信息、请参见 "http://linux.die.net/man/5/nfs4_acl"。

如果NFSv4.1 ACL设置不正确(或者客户端和服务器无法解析名称字符串)、则ACL可能无法按预期运行、或者ACL更改可能无法应用并引发错误。

示例错误包括：

Failed setxattr operation: Invalid argument
Scanning ACE string 'A:: user@rwaDxtTnNcCy' failed.

显式拒绝

NFSv4.1权限可以包括所有者、组和所有人的显式拒绝属性。这是因为NFSv4.1 ACL为default-deny、这意味着如果ACE未明确授予ACL、则会拒绝该ACL。显式拒绝属性会覆盖任何访问ACE、无论显式还是非显式。

deny ACE使用属性标记`D`设置。

在以下示例中、组@允许所有读取和执行权限、但拒绝所有写入访问。

sh-4.1$ nfs4_getfacl /mixed
A::ldapuser@domain.netapp.com:ratTnNcCy
A::OWNER@:rwaDxtTnNcCy
D::OWNER@:
A:g:GROUP@:rxtncy
D:g:GROUP@:waDTC
A::EVERYONE@:rxtncy
D::EVERYONE@:waDTC

应尽可能避免拒绝ACE、因为它们可能会造成混乱和复杂；不明确定义的允许ACL会被隐式拒绝。如果设置了拒绝ACE、则在用户希望获得访问权限时、可能会拒绝其访问。

上述一组ACE相当于模式位中的755、这意味着：

  • 所有者拥有完全权限。

  • 组具有只读。

  • 其他用户只读。

但是、即使权限调整为775等效权限、访问也可能会因为对Everyone设置了显式拒绝而被拒绝。

NFSv4.1 ID域映射依赖关系

NFSv4.1利用ID域映射逻辑作为安全层、帮助验证尝试访问NFSv4.1挂载的用户是否确实是他们所宣称的身份。在这些情况下、来自NFSv4.1客户端的用户名和组名称会附加一个名称字符串、并将其发送到Google Cloud NetApp Volumes实例。如果该用户名/组名称和ID字符串组合不匹配、则用户和/或组将被强制转换为客户端文件中指定的默认无人用户 /etc/idmapd.conf。

要确保正确遵守权限、需要使用此ID字符串、尤其是在使用NFSv4.1 ACL和/或Kerberos时。因此、要确保客户端和Google Cloud NetApp卷之间的一致性、以正确解析用户和组名称身份、需要使用LDAP服务器等名称服务服务器依赖项。

Google Cloud NetApp卷使用静态默认ID域名值 defaultv4iddomain.com。NFS客户端的ID域名设置默认为DNS域名，但您可以在中手动调整ID域名 /etc/idmapd.conf。

如果在Google Cloud NetApp卷中启用了LDAP、则Google Cloud NetApp卷会自动执行NFS ID域、以更改为为DNS中的搜索域配置的内容、而客户端无需进行修改、除非它们使用不同的DNS域搜索名称。

当Google Cloud NetApp卷可以解析本地文件或LDAP中的用户名或组名称时、将使用域字符串、不匹配的域ID将强制转换为无人。如果Google Cloud NetApp卷在本地文件或LDAP中找不到用户名或组名称、则会使用数字ID值、NFS客户端会正确解析该名称(这与NFSv3行为类似)。

如果不更改客户端的NFSv4.1 ID域以匹配Google Cloud NetApp卷正在使用的内容、您会看到以下行为：

  • 在Google Cloud NetApp卷中具有本地条目的UNIX用户和组(例如、本地UNIX用户和组中定义的root)将强制转换为nobody值。

  • 如果NFS客户端与Google Cloud NetApp卷之间的DNS域不同、则在LDAP中具有条目的UNIX用户和组(如果将Google Cloud NetApp卷配置为使用LDAP)会将数据强制转换为无用户。

  • 没有本地条目或LDAP条目的UNIX用户和组使用数字ID值并解析为NFS客户端上指定的名称。如果客户端上不存在任何名称、则仅显示数字ID。

下面显示了上述情形的结果：

# ls -la /mnt/home/prof1/nfs4/
total 8
drwxr-xr-x 2 nobody nobody 4096 Feb  3 12:07 .
drwxrwxrwx 7 root   root   4096 Feb  3 12:06 ..
-rw-r--r-- 1   9835   9835    0 Feb  3 12:07 client-user-no-name
-rw-r--r-- 1 nobody nobody    0 Feb  3 12:07 ldap-user-file
-rw-r--r-- 1 nobody nobody    0 Feb  3 12:06 root-user-file

如果客户端ID域和服务器ID域匹配、则相同文件列表的显示方式如下：

# ls -la
total 8
drwxr-xr-x 2 root   root         4096 Feb  3 12:07 .
drwxrwxrwx 7 root   root         4096 Feb  3 12:06 ..
-rw-r--r-- 1   9835         9835    0 Feb  3 12:07 client-user-no-name
-rw-r--r-- 1 apache apache-group    0 Feb  3 12:07 ldap-user-file
-rw-r--r-- 1 root   root            0 Feb  3 12:06 root-user-file

有关此问题描述 以及如何解决此问题的详细信息、请参见"NFSv4.1和nobody用户/组。 "

Kerberos依赖关系

如果您计划对NFS使用Kerberos、则必须对Google Cloud NetApp卷具有以下要求：

  • Kerberos分发中心服务(KDC)的Active Directory域

  • Active Directory域、其中用户和组属性填充了用于LDAP功能的UNIX信息(Google Cloud NetApp卷中的NFS Kerberos需要用户SPN到UNIX用户映射才能正常运行。)

  • 已在Google Cloud NetApp卷实例上启用LDAP

  • DNS服务的Active Directory域

NFSv4.1和nobody用户/组

NFSv4.1配置中最常见的问题之一是、如果列表中使用`ls`显示的文件或文件夹属于`user：group` combination of nobody：nobody。

例如：

sh-4.2$ ls -la | grep prof1-file
-rw-r--r-- 1 nobody nobody    0 Apr 24 13:25 prof1-file

数字ID为`99`。

sh-4.2$ ls -lan | grep prof1-file
-rw-r--r-- 1 99 99    0 Apr 24 13:25 prof1-file

在某些情况下、文件可能会显示正确的所有者、但会显示组`nobody`。

sh-4.2$ ls -la | grep newfile1
-rw-r--r-- 1 prof1  nobody    0 Oct  9  2019 newfile1

谁不是谁？

NFSv4.1中的`nobody`用户与`nfsnobody`用户不同。您可以运行`id`命令来查看NFS客户端如何识别每个用户：

# id nobody
uid=99(nobody) gid=99(nobody) groups=99(nobody)
# id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

使用NFSv4.1时、`nobody`用户是由`idmapd.conf`文件定义的默认用户、可定义为要使用的任何用户。

# cat /etc/idmapd.conf | grep nobody
#Nobody-User = nobody
#Nobody-Group = nobody

为什么会发生这种情况？

由于通过名称字符串映射实现安全性是NFSv4.1操作的关键要素、因此、如果名称字符串不匹配、则默认行为是将该用户强制转换为通常无法访问用户和组所拥有的文件和文件夹的用户。

如果您在文件列表中看到用户和/或组的`nobody`、则这通常意味着NFSv4.1中的某些内容配置不当。区分大小写可以在此处发挥作用。

例如、如果正在访问导出的是user1@CVSDEMO.LOCAL (UID 1234、GID 1234)、则Google Cloud NetApp卷必须能够找到user1@CVSDEMO.LOCAL (UID 1234、GID 1234)。如果Google Cloud NetApp卷中的用户为USER1@CVSDEMO.LOCAL、则不匹配(大写用户1与小写用户1)。在许多情况下、您可以在客户端上的消息文件中看到以下内容：

May 19 13:14:29 centos7 nfsidmap[17481]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'CVSDEMO.LOCAL'
May 19 13:15:05 centos7 nfsidmap[17534]: nss_getpwnam: name 'nobody' does not map into domain 'CVSDEMO.LOCAL'

客户端和服务器都必须同意用户确实是他们声称的用户、因此您必须检查以下内容、以确保客户端看到的用户与Google Cloud NetApp Volumes看到的用户具有相同的信息。

  • *NFSv4.x ID域。*客户端： idmapd.conf`file；Google Cloud NetApp Volumes使用 `defaultv4iddomain.com、无法手动更改。如果将LDAP与NFSv4.1结合使用、则Google Cloud NetApp Volumes会将ID域更改为DNS搜索域所使用的域、这与AD域相同。

  • *用户名和数字ID。*这将确定客户端查找用户名的位置并利用名称服务开关配置—客户端： `nsswitch.conf`和/或本地passwd和组文件；Google Cloud NetApp卷不允许对此进行修改、但会在启用LDAP后自动将其添加到配置中。

  • *组名称和数字ID。*这将确定客户端查找组名称的位置、并利用名称服务开关配置(客户端：和/或本地passwd和组文件) nsswitch.conf；Google Cloud NetApp Volumes不允许对此进行修改、但会在启用LDAP后自动将其添加到配置中。

在几乎所有情况下、如果您在客户端的用户和组列表中看到 nobody、则问题是Google Cloud NetApp卷和NFS客户端之间的用户或组名称域名ID转换。要避免这种情况、请使用LDAP解析客户端和Google Cloud NetApp卷之间的用户和组信息。

查看客户端上NFSv4.1的名称ID字符串

如果您使用的是NFSv4.1、则会在NFS操作期间进行名称-字符串映射、如上所述。

除了使用`/var/log/messages`查找具有NFSv4 ID的问题描述 之外、您还可以使用 "nfsidmap -l" 命令以查看哪些用户名已正确映射到NFSv4域。

例如、以下是客户端可找到的用户NetApp访问NFSv4.x挂载后命令的输出：

# nfsidmap -l
4 .id_resolver keys found:
  gid:daemon@CVSDEMO.LOCAL
  uid:nfs4@CVSDEMO.LOCAL
  gid:root@CVSDEMO.LOCAL
  uid:root@CVSDEMO.LOCAL

如果某个用户未正确映射到NFSv4.1 ID域(在本例中为`netapp-user`)、则会尝试访问同一挂载并触摸某个文件、系统会按预期为其分配`nobody：nobody`。

# su netapp-user
sh-4.2$ id
uid=482600012(netapp-user), 2000(secondary)
sh-4.2$ cd /mnt/nfs4/
sh-4.2$ touch newfile
sh-4.2$ ls -la
total 16
drwxrwxrwx  5 root   root   4096 Jan 14 17:13 .
drwxr-xr-x. 8 root   root     81 Jan 14 10:02 ..
-rw-r--r--  1 nobody nobody    0 Jan 14 17:13 newfile
drwxrwxrwx  2 root   root   4096 Jan 13 13:20 qtree1
drwxrwxrwx  2 root   root   4096 Jan 13 13:13 qtree2
drwxr-xr-x  2 nfs4   daemon 4096 Jan 11 14:30 testdir

nfsidmap -l`输出会在屏幕上显示用户`pcuser、但不会显示`netapp-user`；这是我们导出策略规则中的匿名用户(65534)。

# nfsidmap -l
6 .id_resolver keys found:
  gid:pcuser@CVSDEMO.LOCAL
  uid:pcuser@CVSDEMO.LOCAL
  gid:daemon@CVSDEMO.LOCAL
  uid:nfs4@CVSDEMO.LOCAL
  gid:root@CVSDEMO.LOCAL
  uid:root@CVSDEMO.LOCAL