Docker多阶段构建中COPY --from报错排查（Ubuntu 18.04）

你遇到的这个Container ID 165578 cannot be mapped to a host ID错误，核心原因是本地Ubuntu 18.04的Docker开启了用户命名空间（User Namespace）映射，而你的CI环境默认没开这个配置，导致两边的构建行为不一致。

为什么会触发这个错误？ #

Alpine镜像里的部分文件会使用非root的用户ID（比如报错里的165578），当Docker启用了用户命名空间映射时，它会尝试把容器内的用户ID映射到主机上合法的用户ID。但scratch镜像本身是空的，没有任何用户或组的元数据，Docker在处理复制操作时没办法完成这个映射，就直接抛出了错误。而CI环境通常默认关闭了用户命名空间，所以复制操作能正常执行。

给你几个可行的解决办法： #

1. 临时关闭用户命名空间映射（快速验证） #

• 打开Docker的配置文件/etc/docker/daemon.json，如果没有就新建一个。
• 检查里面有没有"userns-remap": "default"这样的配置，有的话直接注释或者删掉。
• 重启Docker服务生效：

  sudo systemctl restart docker
  

  之后再重新构建镜像，应该就能正常完成复制了。

2. 修改Dockerfile，强制指定文件所有者 #

在COPY命令里加上--chown=root:root参数，强制把复制的所有文件的所有者设为root，这样Docker就不需要处理用户ID的映射逻辑了：

FROM alpine AS build
FROM scratch
COPY --from=build --chown=root:root / /

这种方法不需要改动Docker的全局配置，适合不想调整系统设置的场景。

3. 配置用户命名空间映射规则（进阶方案） #

如果你不想关闭用户命名空间，也可以手动修改映射规则，让容器内的ID能对应到主机的合法ID。不过这个配置比较复杂，需要编辑/etc/subuid和/etc/subgid文件添加对应映射，然后重启Docker。对于你的场景来说，前两种方法会更简单直接。

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