本文详解如何解决在 aws-glue-libs 官方镜像（如 glue_libs_4.0.0_image_01）中因用户权限不匹配导致的 permission denied 错误，重点涵盖目录挂载、pip 安装、pytest 缓存写入等典型场景，并提供可落地的配置与最佳实践。
本文详解如何解决在 aws-glue-libs 官方镜像（如 glue_libs_4.0.0_image_01）中因用户权限不匹配导致的 permission denied 错误，重点涵盖目录挂载、pip 安装、pytest 缓存写入等典型场景，并提供可落地的配置与最佳实践。
在基于 AWS Glue 官方 Docker 镜像（如 public.ecr.aws/glue/aws-glue-libs:glue_libs_4.0.0_image_01）构建本地开发与 CI/CD 测试流水线时，一个常见却易被忽视的问题是：容器内用户 glue_user 对宿主机挂载目录无写权限。这直接导致 mkdir、pip install -t 和 pytest 缓存创建等操作失败，抛出典型的 [Errno 13] Permission denied 错误。
根本原因在于 Linux 文件系统权限模型：Docker 的 --mount=type=bind 会将宿主机目录原样挂载进容器，其 UID/GID（例如 1000:1000）不会自动映射为容器内 glue_user（UID 1001）的权限主体。执行 ls -l 查看挂载目录时，常可见如下状态：
drwxrwxr-x 2 1000 1000 4096 Apr 18 05:18 test # 宿主机用户 ID，非 glue_user drwxr-xr-x 2 glue_user root 4096 Nov 15 11:20 jupyter_workspace # 容器内原生目录，glue_user 可写
因此，即使容器以 glue_user 身份运行，它也无法向 test/ 或 libs/ 等挂载路径写入文件——这是典型的“UID 不一致”问题，而非 Docker 或 Glue 配置缺陷。
✅ 推荐解决方案：解耦权限依赖，重定向敏感写入路径
最稳健、无需修改宿主机权限或重建镜像的方法，是避免在挂载路径中进行任何需要写权限的操作，转而将临时文件、缓存、依赖安装目标等重定向至容器内 glue_user 拥有完全控制权的路径（如 /tmp 或 /home/glue_user/workspace 下的子目录）。
1. 重定向 pytest 缓存目录（立即生效）
在宿主机 test/ 目录下创建 pytest.ini 配置文件：
# ./test/pytest.ini [pytest] cache_dir = /tmp/pytest-cache/ junit_family = xunit2
该配置强制 pytest 将 .pytest_cache/ 写入容器内 /tmp（glue_user 默认拥有完整读写权限），彻底规避挂载目录权限问题。
2. 安全安装 Python 依赖（推荐 -t + /tmp）
修改 docker run 命令中的 pip 安装步骤，将 target 目录设为 /tmp/deps 而非挂载路径下的 deps/：
docker run \
--mount=type=bind,source=./test,target=/home/glue_user/workspace/test \
--mount=type=bind,source=./libs,target=/home/glue_user/workspace/libs \
-w /home/glue_user/workspace \
-e DISABLE_SSL=true \
-e "PYTHONPATH=$PYTHONPATH:/tmp/deps" \ # 注意：指向 /tmp/deps
--rm -p 4040:4040 -p 18080:18080 \
--name glue_unit_tests \
public.ecr.aws/glue/aws-glue-libs:glue_libs_4.0.0_image_01 \
-c "mkdir -p /tmp/deps && \
pip install -r test/requirements.txt -r libs/requirements.txt -t /tmp/deps && \
cd test && pytest --cache-dir /tmp/pytest-cache/ || exit 1"✅ 优势：/tmp 是容器内标准临时目录，glue_user 无需额外权限即可读写；PYTHONPATH 正确生效；所有中间产物隔离于挂载路径之外。
3. （可选）预设用户 UID 启动容器（高级场景）
若需长期复用挂载目录写入（如生成测试报告），可在启动时显式指定用户 UID，使其与宿主机一致：
docker run \ --user 1000:1000 \ # 强制以 UID 1000/GID 1000 运行（需确保宿主机该用户存在且有权限） --mount=type=bind,source=./test,target=/home/glue_user/workspace/test \ ...
⚠️ 注意：此方式要求宿主机 ./test 目录对 UID 1000 可写，且需确认 glue_user 在镜像中是否允许降权运行（AWS Glue 镜像默认限制 root 外用户权限，建议优先采用方案 1 & 2）。
⚠️ 关键注意事项与最佳实践
- 永远不要 chmod 777 挂载目录：破坏最小权限原则，CI 环境中尤其危险；
- 避免 --privileged 启动：Glue 镜像设计为非特权运行，启用后引入安全风险且违反 AWS 最佳实践；
- 生产环境迁移提示：本地测试通过后，务必使用 --additional-python-modules 参数（配合 S3 上的 zip-of-wheels）将依赖注入真实 Glue Job，确保环境一致性；
- 镜像版本兼容性：glue_libs_4.0.0_image_01 基于 Spark 3.3.0，若升级至 Glue 5.x（Spark 3.5.4），请同步更新镜像标签为 public.ecr.aws/glue/aws-glue-libs:5 并验证依赖兼容性。
通过以上结构化调整，您不仅能快速修复 Permission denied 错误，更能建立符合云原生规范、可审计、可复现的本地 Glue 开发测试流程——让数据工程迭代更敏捷、更可靠。
