Dockerfile COPY 后执行 chmod 报 Operation not permitted

从非 root 基础镜像构建时，COPY 已成功把脚本放进镜像，下一条 RUN chmod +x 却失败：

chmod: changing permissions of '/app-entrypoint.sh': Operation not permitted

一种需要核对的组合是：基础镜像设置了非 root 的 USER，而新复制的脚本仍属于 UID 0。USER 决定后续 RUN 的执行身份，不会让普通 COPY 自动把文件属主改成该用户。

以下针对 Linux 容器镜像。只读挂载、immutable 属性、系统调用过滤也可能产生权限错误；先确认执行用户和文件属主确实不匹配，再采用这里的处理。

COPY 能成功，不代表 RUN 有权修改文件模式

可以在失败步骤之前临时加入只读检查，前提是基础镜像包含这些工具：

RUN id && ls -ln /app-entrypoint.sh

查看执行身份和脚本的数字 UID、GID。即使本 Dockerfile 没写 USER，也可能继承了基础镜像的默认用户。相反，COPY 没有指定 --chown 时，新文件的 UID、GID 默认都是 0。

Linux 上修改普通文件模式，需要调用进程的有效 UID 与文件属主一致，或者具备相应权限。文件对某个用户可读、可执行，甚至可写，并不表示这个用户就是文件属主、可以任意 chmod。

若检查显示 RUN 已以足够权限执行，不能继续把问题归为这一组合。应结合实际构建器、挂载、安全策略和失败操作继续缩小范围，而不是反复切换 USER 或加大权限。

只为运行脚本，复制时设置执行位即可

如果脚本不需要由应用用户修改，可以保留 root 属主，在复制时直接确定模式：

# syntax=docker/dockerfile:1
FROM your-base-image:version
COPY --chmod=0755 custom-entrypoint.sh /app-entrypoint.sh

这是需要合并到原 Dockerfile 的片段，基础镜像和文件名均为占位值。COPY --chmod 的八进制形式需要 Dockerfile 前端 1.2 或更高版本，并使用支持该语法的构建器；这不是 Docker Engine 的版本号。Windows 容器不支持这里的 --chmod、--chown 用法。

0755 让属主可写、其他用户可读和执行，不授予所有人写权限。脚本及其父目录还必须满足实际运行用户的读取、路径遍历要求。包含敏感信息的文件不应为了省事统一设置为这个模式，更不应把整个应用目录递归改成 777。

这个片段保留基础镜像的 USER，不需要仅为设置执行位把应用改成 root 运行。它也没有替换 ENTRYPOINT 或 CMD：修复文件模式不会自动决定程序如何启动，应保留原镜像的启动约定。

确实需要修改属主时，明确指定 UID 和 GID

若文件的用途要求应用用户修改它，可以用经过确认的数字身份指定所有权。例如应用实际使用 UID 1001、GID 1001 时：

COPY --chown=1001:1001 --chmod=0755 \
    custom-entrypoint.sh /app-entrypoint.sh

1001:1001 只是示例，不能因为某个基础镜像曾使用这个值，就推广到所有非 root 镜像。先确认当前镜像的实际用户和组。使用用户名、组名时，还需要镜像内的 /etc/passwd、/etc/group 能解析这些名称；使用数字身份不依赖这个名称查询。

对启动脚本而言，交给应用用户所有并非总有必要。只要求执行时，前一种 root 所有且不可由应用随意改写的方案通常已经足够；需要写入的数据应放到其专用目录，不要把运行权限问题一并变成整个代码树的属主调整。

使用 RUN chmod 时，切回用户的顺序不能颠倒

如果现有构建流程必须用 RUN 修改模式，可以仅在安装步骤临时使用 root，然后恢复经过确认的原运行身份：

FROM your-base-image:version
USER 0
COPY custom-entrypoint.sh /app-entrypoint.sh
RUN chmod 0755 /app-entrypoint.sh
USER 1001:1001

最后一行同样是占位身份，应恢复该项目原本要求的用户与组，而不是机械复制。若在 RUN chmod 之前就切回非属主用户，仍可能得到原来的错误。还要检查恢复点之后的构建步骤是否依赖其他身份，避免把临时安装身份泄漏到最终运行配置。

不要通过 --privileged 或关闭 seccomp 来修复已经确认的普通属主不匹配。它们放宽的是其他安全边界，也不能代替清楚的文件权限设计。

构建通过后，再核对实际启动

重新构建后检查脚本的 UID、GID、模式及最终运行用户，再按原启动命令验证应用。执行位正确仍可能遇到解释器不存在、脚本换行格式不兼容或运行时挂载遮盖文件；这些需要按新的具体错误处理，不能继续扩大权限。

诊断用的 id、ls 步骤核对结束后可以移除。保留修改前的 Dockerfile 和可回退镜像，先在隔离环境验证；回退时恢复配置并重新使用旧镜像。不要靠进入某个运行容器临时 chmod 作为最终修复，否则重新创建容器后仍会回到镜像中的旧状态。