将 EFS 接入点挂载到 ECS 卷时出现问题

Posted 2023-02-19

【中文标题】将 EFS 接入点挂载到 ECS 卷时出现问题

【英文标题】：Trouble mounting EFS Access Point to ECS Volume

【发布时间】：2021-01-11 10:52:50

【问题描述】：

我在尝试通过 EFS 访问点将 ECS 卷挂载到 EFS 时遇到问题。

任务角色设置为对该文件系统的 ClientWrite、ClientRead 和 ClientRootAccess。

使用 posix userid 1001 和 groupid 1001 设置接入点，权限为 755。

集群和文件系统位于正确的 VPC 中。

但 ECS 未能启动任务并出现此错误：

来自守护程序的错误响应：无法复制文件信息 /var/lib/ecs/volumes/task-name：chown 失败 /var/lib/ecs/volumes/任务名称

如果我在 root 中将接入点的 POSIX 用户 ID 和 groupid 设置为 0，我就能够启动任务。但我觉得它不是共享 FS 中出于安全原因的最佳选择。

经过一些常规搜索后，我假设在挂载卷后，容器或其主机的用户已从 root 更改，这与 Dockerfile 中任何进一步的文件/目录操作相混淆。 AWS 接入点文档指出：

启用用户强制后，Amazon EFS 将替换 NFS 客户端的 具有在接入点上配置的身份的用户和组 ID 用于所有文件系统操作。

因为我认为/var/lib/ecs/volumes/... 实际上要么是容器目录，要么是主机目录。

我该如何规避这个问题？

仅供参考：该任务在 Spot 实例集群中运行，因此在这种情况下手动挂载卷不是理想的解决方案

【问题讨论】：

嗨。我遇到了同样的问题。我通过删除 Dockerfile 中的现有文件夹解决了这个问题。似乎当图像中存在文件夹时，docker（或 ECS ？）想要 chown/chmod/copy 到目标中......

【参考方案1】：

您尝试运行的 Docker 映像中定义的 uid/gid 与您尝试使用的 1001/1001 uid/gid 是否可能不匹配？

我们在获取已定义卷的基本映像并尝试更改映像中主要用户的 uid 时遇到了同样的错误。由于您无法更改卷的文件所有权或权限，因此一旦创建，docker 守护程序将尝试将原始 uid 所有权应用于已安装的 EFS 卷，从而导致 EFS 访问点阻止所有权/权限的更改。

您可以通过在本地进入 docker 容器或运行 docker exec 到 ls -la /path/to/container/folder 来检查这一点，并检查该文件夹的所有权是否设置为具有 uid 1001 的用户。

【参考方案2】：

我最近遇到了同样的问题。我有一个带有访问点的 EFS，它允许 755 访问 1001:1001 (ec2-user)。

通过 AP 安装和访问工作正常，但我在使用卷并将它们安装在 ECS 中时遇到了同样的错误。

最后，对我来说快速简单的解决方法是将 root 权限 ("elasticfilesystem:ClientRootAccess") 添加到文件系统策略中。