Alpine 容器 tar 报 Operation not permitted：检查 fchmodat2 与运行时策略

基于较新 Alpine 的容器解压归档时，tar 连续报告 Cannot change mode 和 Operation not permitted。宿主机目录权限没有明显问题，换回旧基础镜像却正常。这时除了挂载权限，还要检查新工具使用的系统调用是否被实际运行时的 seccomp 策略拒绝。

Alpine 3.20 的部分架构曾在这里遇到 fchmodat2 支持不完整的问题：Docker 策略、生成策略时使用的 libseccomp，以及独立 BuildKit，都可能影响结果。不能把所有 tar 权限错误归因这一项，也不能仅凭镜像版本确定根因。

确认是哪一层运行了失败步骤

记录完整失败命令、基础镜像及其架构、目标路径和构建阶段。解压到只读挂载、文件属主与应用用户不匹配、SELinux 文件标签拒绝，仍应按它们的具体证据处理。

在客户端可用下面的只读入口核对执行方：

docker version
docker info
docker buildx ls

关注 Server 版本和正在使用的 builder。客户端升级了，不表示远程 Docker 服务或 docker-container 驱动启动的 BuildKit 也升级了。Docker-in-Docker 环境里还要确认哪一个守护进程创建了构建容器。

同样，镜像内安装了新版 libseccomp，并不一定改变宿主运行时已经为它设置的过滤策略。库版本应按实际运行时或 builder 的安装方式检查，不从另一台电脑的包列表推断。

错误要对应到实际系统调用

seccomp 可以按系统调用及参数放行或拒绝访问。默认策略采用允许列表；工具改用一个旧策略尚未认识的新调用时，可能在原有文件权限满足的情况下仍得到拒绝。

分析已有审计或诊断记录，判断失败是否确实对应 fchmodat2，以及返回的是 EPERM、ENOSYS 还是其他错误。缺少相关记录时，不能凭一行 Operation not permitted 排除普通权限和文件系统限制。涉及内核调用的追踪应按环境权限在隔离诊断条件下安排，不额外在生产构建中开放所有权限。

历史上 Docker 的相关策略支持进入了 26.0.0，以及 25.0.3、24.0.10、23.0.10 分支修订；libseccomp 2.5.5 加入了这一阶段的新调用表。发行版也可能把支持回移到较低版本号，例如带发行版修订后缀的包。判断时应核对实际补丁，不能只比较主版本字符串。

这些数字是历史修复边界，不是当前生产环境应长期停留的推荐版本。选用供应方支持、包含所需策略及系统调用表更新的运行时与依赖；旧版本达到某个最小数字，也不代表其他兼容性和安全更新已经满足。

构建失败时，把 BuildKit 一起纳入升级范围

若运行容器正常而镜像构建仍失败，核对 BuildKit 自己使用的运行时和策略依赖。独立 builder 的镜像、远程 builder 或 CI 执行镜像，有自己的版本与生命周期。只重启本机 Docker 或更新 CLI，不能替换这些执行方。

通过原安装渠道更新对应的 Docker、BuildKit 和相关运行时依赖，保留构建配置、镜像摘要、版本记录及受支持的回退镜像。升级可能中断构建或容器，应安排维护窗口，在隔离环境用原目标架构验证后切换。

基础镜像临时回退也必须选择仍被维护的版本，并保留依赖兼容性检查。换架构、跳过 chmod 或关闭解压错误，都会改变执行条件，不能据此宣称目标构建已修好。

不把关闭 seccomp 留作长期修复

seccomp=unconfined 会取消相关过滤，可以在受控诊断中帮助判断策略是否参与失败，但不是只放行 fchmodat2，也不是所有权限问题的检测开关。对带凭据、业务挂载或不受信任代码的构建，不应随手取消隔离来重试。

即便受控比较有效，也应撤回诊断例外，更新匹配的策略与运行时后，在正常安全配置下重新验证。--privileged 的放宽范围更大，不能用作这类兼容问题的常驻方案。自定义策略若确有必要，应针对已确认调用按现有安全流程审定，不能从网络复制一个全放行文件。

成功标准是同一目标架构、同一正常构建入口能完成原来的解压和后续步骤，文件权限符合应用要求，且没有保留 unconfined 或 privileged 例外。更新工具不会修复已经失败留下的半成品，应按构建流程重新产生可信镜像。回退运行时或基础镜像可能再次触发原错误，也需保留这项兼容性边界。