GitHub Actions生成的Docker镜像运行时提示权限拒绝

权限不一致的原因 #

从Actions日志可以明确看出：

• ls -l .显示的是**/src/gh-action-test目录**的权限（dr-xr-xr-x，开头的d表示这是目录）
• ls -l gh-action-test是查看该目录内部的文件，显示的是目录里同名可执行文件gh-action-test的权限（-rw-r--r--，无执行权限）

这说明你执行COPY ./target/release/gh-action-test /src/gh-action-test时，源路径./target/release/gh-action-test在GitHub Actions环境中是一个目录，而非本地环境中的可执行文件。COPY命令会将整个目录复制到目标路径，导致镜像中/src/gh-action-test是目录，里面才是可执行文件，但该文件没有执行权限，且你尝试运行的是目录而非文件，最终触发Permission denied错误。

本地编译正常是因为本地的target/release/gh-action-test是可执行文件，COPY时直接复制文件，权限逻辑正常。

解决方法 #

1. 修正Dockerfile的COPY命令 #

确保将可执行文件直接复制到目标目录，而非复制整个目录：

# 替换原COPY命令，将文件复制到/src目录下，保留文件名
COPY ./target/release/gh-action-test /src/

这样即使源路径意外是目录，也会将目录内的可执行文件复制到/src下，后续的chmod和运行命令也能正确作用于文件。

2. 排查GitHub Actions中的编译产物 #

检查Actions中编译步骤的输出，确认target/release/gh-action-test是文件而非目录：

• 若使用actions/upload-artifact和actions/download-artifact传递编译产物，确保上传的是文件而非目录，可在上传前添加ls -l target/release/命令验证产物类型。
• 若编译脚本存在逻辑错误（比如误将可执行文件路径创建为目录），需修正编译流程。

3. 使用Docker多阶段构建（推荐） #

直接在Docker内部完成Rust编译，避免依赖外部产物的路径/权限问题：

# 构建阶段：编译Rust项目
FROM rust:1.79 AS builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
COPY src ./src
RUN cargo build --release

# 运行阶段：使用轻量镜像打包可执行文件
FROM debian:bookworm-slim
WORKDIR /src
# 从构建阶段复制编译好的可执行文件
COPY --from=builder /app/target/release/gh-action-test .
# 添加执行权限
RUN chmod +x gh-action-test
# 设置启动命令
CMD ["./gh-action-test"]

这种方式完全隔离了本地与GitHub Actions的环境差异，确保产物是正确的可执行文件，且权限可控。

4. 验证镜像内的文件状态 #

在Dockerfile中添加验证步骤，确保复制后的是文件而非目录：

RUN test -f /src/gh-action-test || (echo "gh-action-test is not a file" && exit 1)

若验证失败，可在Actions日志中快速定位问题根源。

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