Docker文件系统权限在GitHub Actions与本地表现差异原因咨询

我使用官方Backstage CLI生成了Dockerfile，在本地Mac及同事的Windows机器上执行docker build可正常完成，但在GitHub Actions或Microsoft ADO中构建时，出现文件系统权限错误：

Step 7/11 : RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz
 ---> Running in b20314a0495a
tar: packages: Cannot mkdir: Permission denied
tar: packages/app/package.json: Cannot open: No such file or directory
tar: packages: Cannot mkdir: Permission denied
tar: packages/backend/package.json: Cannot open: No such file or directory
tar: Exiting with failure status due to previous errors

通过添加RUN mkdir -p /app和RUN chown node /app两步后，该Dockerfile可在本地及GitHub Actions上正常构建。我想了解：

1. 为何第一个Dockerfile在本地可成功构建，在GitHub Actions（Linux环境）却失败？
2. GitHub Actions环境需要额外修改目录所有者的原因是什么？是否与Docker版本有关？

本地与GitHub Actions构建差异的核心原因 #

• 本地Docker的权限适配特性：
  Mac和Windows上的Docker运行在虚拟机中，但Docker Desktop做了权限兼容处理——它会自动将宿主机用户权限映射到容器内部，或者默认赋予容器内操作足够的目录读写权限。比如在Mac环境下，容器内的node用户默认能对/app目录执行写入操作，这是Docker Desktop帮你掩盖了权限不匹配的问题。
• GitHub Actions的原生Linux环境特性：
  GitHub Actions使用的是原生Linux宿主机，Docker直接运行在该环境中，没有Docker Desktop的权限适配逻辑。官方Backstage CLI生成的Dockerfile通常会包含USER node指令，切换到非root用户执行后续构建步骤，但/app目录是由基础镜像的root用户创建的，node用户没有该目录的写入权限，因此解压tar包时无法创建packages子目录，触发权限报错。

为何需要修改目录所有者 #

这和Docker版本关系不大，核心是用户上下文与目录权限的匹配问题：

• 生成的Dockerfile切换到node用户后，后续所有操作都以该用户身份执行，但/app目录的所有权仍属于root，node用户没有写入权限。本地Docker Desktop的适配逻辑让这个问题没有暴露，但在权限检查更严格的原生Linux环境（如GitHub Actions）中，这个权限冲突就会直接导致构建失败。
• 添加RUN mkdir -p /app && chown node /app的作用是提前将/app目录的所有者修改为node，确保后续以node用户执行解压等写入操作时，拥有足够的权限创建子目录和文件。

内容的提问来源于stack exchange，提问作者orcaman