Filestore 支持以下文件系统协议：
NFSv3
- 适用于所有服务层级。
- 支持客户端与服务器之间的双向通信。
- 使用多个端口。
- 为网络流量和操作创建信任通道。
- 支持快速设置标准 POSIX 访问权限。
NFSv4.1
- 可在可用区级、区域级和企业级服务层级中使用。
- 兼容新型防火墙配置并支持网络安全
合规要求。
- 通信始终由客户端发起，并且始终通过单个服务器端口
2049提供。 - 支持客户端和服务器身份验证。
- 需要 RPCSEC_GSS 身份验证 该实现是使用 LDAP 实现的 和 Kerberos， 两者均在 Managed Service for Microsoft Active Directory 中提供。
- 支持使用 LDAP 和 Kerberos 进行身份验证 (
krb5)、邮件 完整性检查 (krb5i) 和传输中的数据加密 (krb5p)。 - 为客户端和服务器提供 NFSv4.1 文件 ACL 支持。
- 通信始终由客户端发起，并且始终通过单个服务器端口
每种协议最适合特定用例。下表比较了 每种协议的规范：
| 规范 | NFSv3 | NFSv4.1 |
|---|---|---|
| 支持的服务层级 | 所有服务层级 | 可用区级、区域级和企业级 |
| 双向通信 | 是 | 不会。通信始终由客户端使用服务器端口 2049 发起。 |
| 身份验证 | 否 | 是。需要使用 RPCSEC_GSS 身份验证（使用 LDAP 和 Kerberos 实现），两者均在 Managed Service for Microsoft Active Directory 中提供。 |
| 支持文件或目录访问控制列表 (ACL) | 否 | 是。每个列表最多支持 50 个访问控制条目 (ACE)。 |
| 群组支持 | 最多 16 个群组 | 连接到代管式 Microsoft AD 后，支持无限数量的群组。 |
| 安全设置 | sys。创建信任渠道。 |
sys。创建信任通道。krb5。对客户端和服务器进行身份验证。krb5i。提供身份验证和消息完整性检查。krb5p。提供身份验证、消息完整性检查和传输中数据加密。 |
| 操作延迟时间 | 无 | 选择安全等级后，操作延迟时间会增加。 |
| 恢复类型 | 无状态 | 有状态 |
| 文件锁定类型 | 网络锁定管理器 (NLM)。锁由客户端控制。 | 基于租期的通知锁定。锁由服务器控制。 |
| 支持客户端故障 | 否 | 是 |
| 支持专用服务访问通道 | 否 | 否 |
NFSv3 的优势
NFSv3 协议可快速设置标准 POSIX 访问权限。
NFSv3 限制
以下是 NFSv3 限制的列表：
- 不支持专用服务访问通道。
- 缺少客户端和服务器身份验证及加密功能。
- 缺少客户端故障处理。
NFSv4.1 的优势
NFSv4.1 协议使用 RPCSEC_GSS 身份验证方法，该方法使用 LDAP 和 Kerberos 实现，用于提供客户端和服务器身份验证、消息完整性检查和传输中的数据加密。
这些安全功能使得 NFSv4.1 协议与现代 网络安全合规性要求：
使用单一服务器端口
2049进行所有通信，有助于简化流程 防火墙配置。支持 NFSv4.1 文件访问权限控制列表 (ACL)。
- 每个 ACL 最多支持每个文件或目录 50 个访问控制条目 (ACE)。其中包括继承记录。
使用代管式 Microsoft AD 集成时，支持无限数量的群组。
通过基于租期的咨询锁定，支持更好地处理客户端故障。
- 客户端必须验证与服务器的持续连接。如果客户 租期不续订时，服务器会释放锁，而文件会变为 可供任何其他通过锁定租用请求访问的客户端使用。 在 NFSv3 中，如果客户端在锁定状态下被删除，其他客户端（例如新的 GKE 节点）将无法访问该文件。
支持有状态恢复。
- 与 NFSv3 不同，NFSv4.1 是一种基于 TCP 和连接的有状态协议。恢复后，可以恢复上一个会话中客户端和服务器的状态。
Managed Service for Microsoft Active Directory
而 Managed Service for Microsoft Active Directory (Managed Microsoft AD) 并非严格要求，它是唯一能够 支持 LDAP 和 Kerberos，这两者都是 Filestore NFSv4.1 协议。
强烈建议管理员使用 Managed Service for Microsoft Active Directory (Managed Microsoft AD) 来实现和管理 LDAP 和 Kerberos。
作为 Google Cloud 的代管式解决方案，Managed Microsoft AD 提供 具备以下优势：
提供多区域部署，最多支持在同一网域中部署 5 个区域。
- 确保用户及其各自的登录服务器均处于
支持 POSIX RFC 2307 和 RFC 2307bis、 NFSv4.1 实现的要求。
自动处理唯一标识符 (UID) 和全局唯一标识符 (GUID) 用户 映射。
您可以在托管式 Microsoft AD 中创建用户和群组，也可以将其迁移到托管式 Microsoft AD。
管理员可以通过当前的本地服务器创建网域信任， Active Directory (AD) 和 LDAP 域。通过这个选项 则不必执行迁移
提供服务等级协议 (SLA)。
访问权限控制和其他行为
在 Linux 上通过以下方式管理 Filestore NFSv4.1 ACE： 命令：
nfs4_setfacl：在文件或目录上创建或修改 ACE。nfs4_getfacl：列出 文件或目录上的 AdWords 广告系列实验。
每个 ACL 最多支持 50 个 ACE。系统保留 6 个条目以供自动生成 由客户端
chmod操作创建的 ACE。这些 ACE 在创建后可以修改。代表模式位数的自动生成的 ACE 记录按以下优先顺序列出：
OWNER@的DENY and ALLOW ACEsDENY and ALLOW ACEs（针对GROUP@）EVERYONE@的DENY and ALLOW ACEs如果已经存在此类 ACE，系统会根据新应用的模式位对其进行重复使用和修改。
Filestore NFSv4.1 支持仅在以下位置检查所需访问权限： POSIX 模式
RWX（读取、写入和执行）。它不会区分 用于修改内容或SETATTR的write append和write操作 规范nfs4_setfacl实用程序也接受RWX作为快捷方式， 并自动启用所有相应的标记。nfs4_getfacl不会自行对主账号进行任何转换。通过nfs4_getfacl实用工具将显示UID和GUID多个主账号因此，系统会显示特殊的OWNER@、GROUP@和EVERYONE@主账号。无论是否使用代管式 Microsoft AD，在使用
AUTH-SYS和nfs4_setfacl实用程序时，管理员都必须指定数字UID和GUID，而不是用户名。此实用程序无法 将名称转换为这些值。如果未正确提供，Filestore 实例将默认为nobodyID。为文件（甚至受继承的 ACE 影响的文件）指定写入权限时，ACE 必须同时包含
w（写入）和a（附加）标志。检查
SETATTR的权限时，返回的响应与POSIX类似，如下所示：- 超级用户或
ROOT用户可以执行任何操作。 - 只有文件所有者才能将模式位、ACL 和时间戳设置为
特定时间和群组，例如它所属的
GUID。 - 文件所有者以外的用户可以查看这些属性（包括 ACL）。
- 超级用户或
单个 ACE 同时包含有效权限和仅继承权限。与其他 NFSv4.1 实现不同，Filestore 不会自动复制继承的 ACE，以区分有效 ACE 和仅继承 ACE。
NFSv4.1 限制
以下是 NFSv4.1 的限制列表：
NFSv4.1 协议无法与以下功能结合使用：
NFSv4.1 协议不支持
AUDIT and ALARM ACEs。Filestore 不支持数据访问审核。配置完成后，请勿删除托管式 Microsoft AD 和网络对等互连。这样做会导致 Filestore 共享在装载时无法访问 导致数据无法访问Google Cloud 不 对管理员或用户操作造成的中断负责。
使用任何经过身份验证的 Kerberos 安全设置时，用户可能会遇到一些操作延迟。延迟时间率因服务层级和 安全设置。延迟时间随着安全性的提高而增加 。
不支持数据访问审核。
Filestore NFSv4.1 解决方案需要 RPCSEC_GSS 身份验证。 此身份验证方法仅使用 LDAP 实现 和 Kerberos，均可使用 代管式 Microsoft AD 中。 不支持其他身份验证机制。
不支持专用服务访问通道。
如果您希望 Filestore 实例通过共享 VPC 加入托管式 Microsoft AD，则必须使用
gcloud或 Filestore API。您无法使用 Google Cloud 控制台。受管理的 Microsoft AD 域名不得超过 56 个字符。
如需创建企业实例，您必须运行 直接通过 Filestore API 访问。如需了解详情，请参阅 服务层级。
恢复备份时，新实例必须使用与源实例相同的协议。