为什么 Docker 文件系统权限在 GitHub 操作上表现不同（服务器上的权限被拒绝）

Question

我有一个带有 Dockerfile 的应用程序：

# From here on we use the least-privileged `node` user to run the backend.
USER node
WORKDIR /app


# This switches many Node.js dependencies to production mode.
ENV NODE_ENV production

# Copy repo skeleton first, to avoid unnecessary docker cache invalidation.
# The skeleton contains the package.json of each package in the monorepo,
# and along with yarn.lock and the root package.json, that's enough to run yarn install.
COPY --chown=node:node yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz

这是由官方 Backstage CLI ( https://github.com/backstage/backstage/issues/15421 ) 生成的 dockerfile 的一部分。

当我在我的 Mac 和我同事的 Windows 机器上运行 docker 构建时，构建工作正常。

然而，当我们在 GitHub Actions 或 Microsoft ADO 上尝试相同的构建时，docker 构建失败并出现文件系统权限错误：

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

我做了一些谷歌搜索，发现在 tar 操作之前创建和更改上面的“节点”用户拥有的目录可以解决问题。

所以实际上这个 Dockerfile 在我的机器和 GitHub Actions 上都有效。 请注意前两行 - 这是 Dockerfile 之间的全部区别：

RUN mkdir -p /app
RUN chown node /app

# From here on we use the least-privileged `node` user to run the backend.
USER node
WORKDIR /app


# This switches many Node.js dependencies to production mode.
ENV NODE_ENV production

# Copy repo skeleton first, to avoid unnecessary docker cache invalidation.
# The skeleton contains the package.json of each package in the monorepo,
# and along with yarn.lock and the root package.json, that's enough to run yarn install.
COPY --chown=node:node yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz

我不明白的是：为什么第一个 Dockerfile 构建在 Mac/Windows 上成功，而在 GitHub 操作（Linux？）上失败。 为什么 GitHub Actions 版本需要在文件夹级别进行额外的所有者更改，而 Mac/Windows 版本不需要？ 也许这与Docker版本有关？

Answer 1

我非常确定这个问题具体发生在 Linux 上，因为它在 Windows 和 macOS 上运行在虚拟机中。 它会出现在“真正的 Linux”机器而不是虚拟机中的原因是因为用户 ID 和组 ID 在“docker 主机”和 884065722228588 容器之间共享（更多信息参见此处）

GitHub 操作可能已为包含在 tar.gz 中的 uid/gids 以及 tar.gz 本身指定了权限，而在您本地的 macOS/Windows 上，docker 的专用 VM 没有任何“真实”用户管理使用 Linux。

当我使用 Bitbucket 的 CI 时，我遇到了类似的问题，它有一些关于 uids/gids 的奇怪政策。 这可能是一个类似的案例。