eks使用efs dynamic provisioning 创建非root容器提示 Operation not permitted
内容提要
本文讨论了在AWS EKS中使用EFS动态供给时，非root用户启动容器遇到的“Operation not permitted”错误。该错误源于EFS的access point模式，限制了对uid/gid的修改。建议使用静态供给模式创建PV/PVC，以便顺利修改权限。
延伸解读
EFS 访问点模式为何导致权限错误
在 EKS 中使用 EFS 动态供给时，StorageClass 中的 provisioningMode: efs-ap 会启用 EFS 访问点模式。该模式会强制应用一个操作系统用户和组，并覆盖 NFS 客户端提供的身份信息。因此，容器内非 root 用户无法修改挂载目录的 uid/gid，尝试修改时就会触发“Operation not permitted”。这是该模式的预期行为，并非配置错误。
动态供给与静态供给的权限差异
动态供给依赖 EFS 访问点，客户端对挂载卷只有读写权限，不能更改所有者。而静态供给模式直接挂载 EFS 卷，不经过访问点，因此可以正常修改 uid/gid。如果应用需要非 root 用户运行并调整目录权限，静态供给是更合适的选择。
临时解决方案：指定 uid 和 gid
若必须使用动态供给，可在创建 PVC 后，通过 ls -l 查看对应目录的 uid 和 gid，然后在 Pod 的 securityContext 中设置 runAsUser、runAsGroup 和 fsGroup 为相同的值。这样容器进程就能以匹配的身份访问目录，避免权限错误。注意不同环境生成的 uid/gid 可能不同，需以实际输出为准。
当前限制与社区进展
EFS 动态供给的权限限制已在 GitHub 上有 issue 跟踪，但由于该模式本身的设计意义，目前尚未有明确的解决方案。因此，在非 root 容器场景下，建议优先考虑静态供给，或采用指定 uid/gid 的临时方法。
Q&A
在AWS EKS中，非root用户启动容器时遇到什么错误？
非root用户启动容器时会遇到'Operation not permitted'错误。
为什么在使用EFS的access point模式时无法修改uid/gid？
因为EFS的access point模式限制了对uid/gid的修改，客户端只能拥有使用权，无法修改所有者。
如何避免在EKS中使用EFS动态供给时的权限错误？
可以使用静态供给模式创建PV/PVC，以避免该错误并顺利修改权限。
在创建pod之前需要做什么准备工作？
在创建pod之前，需要先创建PVC并记录其uid和gid，然后在pod的yaml清单中指定这些值。
EFS的dynamic provisioning模式有什么弊端？
EFS的dynamic provisioning模式存在权限修改的限制，导致非root用户无法正常使用。
如何在pod配置中指定uid和gid？
在pod的yaml清单中，可以通过securityContext字段指定fsGroup、runAsUser和runAsGroup来设置uid和gid。
