启用User Namespace后，容器内UID 0被映射为宿主机非特权UID范围（如100000～165535），实现root权限解耦；需正确配置/etc/subuid与/etc/subgid、重启Docker守护进程，并调整挂载目录属主以匹配映射UID。
启用 User Namespace 后，容器内 UID 0（root）不再等同于宿主机 UID 0，而是被映射到宿主机上一段非特权 UID 范围（如 100000～165535），这是目前 Docker 中最有效的 root 权限解耦手段。但直接配 "userns-remap": "default" 很容易因挂载权限、子 ID 分配或镜像硬编码导致容器启动失败或写入拒绝。
配置 /etc/subuid 和 /etc/subgid 是前提，不是可选项
Daemon 启用 userns-remap 前，Docker 必须能在 /etc/subuid 和 /etc/subgid 中查到有效映射段。默认用 "default" 会自动创建用户 dockremap 并写入这两文件，但某些发行版（如 CentOS Stream 9 或最小化安装的 Ubuntu）可能缺失该用户或未预分配范围。
- 手动验证是否存在映射：运行
grep dockremap /etc/subuid，若无输出，需先执行sudo useradd -r -u 100000 dockremap，再补上映射行：echo 'dockremap:100000:65536' | sudo tee -a /etc/subuid /etc/subgid - 不建议复用已有普通用户（如
alice）做 remap，除非你明确控制其 subuid 范围且审计要求严格；否则易与系统服务冲突 - 范围长度必须 ≥65536，否则部分镜像（尤其含大量 group 的 Java 应用）会在容器内触发
groupadd: GID 'xxx' already exists错误
daemon.json 配置后必须重启 dockerd，且不能热重载
systemctl reload docker 不生效 —— userns-remap 是 daemon 初始化阶段读取的全局开关，修改后必须完整重启服务，否则 docker info | grep userns 仍显示 userns: disabled。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 执行
sudo systemctl restart docker后，检查日志：sudo journalctl -u docker --since "1 minute ago" | grep -i remap，确认出现类似Using default remapping user: dockremap:100000:65536 - 重启会导致所有运行中容器终止，生产环境务必安排维护窗口
- 若重启失败并报
failed to start daemon: error initializing graphdriver: failed to get overlay2 mountpoint，大概率是旧版 overlay2 驱动不兼容 userns，需升级 Docker 到 24.0+
绑定挂载（-v）目录的属主必须提前对齐 remap UID
容器内进程以映射后的 UID（如 100000）访问宿主机文件，若挂载目录属主仍是 root 或普通用户（如 1001），则容器内会提示 Permission denied，即使 USER 指令设为非 root 也无效。
- 宿主机上运行：
sudo chown -R 100000:100000 /host/data（注意：此处用的是 remap 起始 UID，不是容器内 UID） - 若挂载的是 NFS 或其他网络文件系统，需确认服务端支持 user namespace 映射（多数 NFSv4.2+ 支持，但需显式开启
fs.nfs.enable_ino64=1等内核参数） - 临时调试可用
--user 100000:100000覆盖运行时 UID，但仅用于验证，不可替代目录属主修正
镜像中硬编码 UID 的行为会被整体偏移，而非“跳过映射”
很多镜像在 Dockerfile 中写 USER 1001，启用 userns-remap 后，该用户在宿主机上实际以 101001（100000 + 1001）运行 —— 这是设计行为，不是 bug。但若应用代码里写死 /etc/passwd 查找 UID 1001 或依赖 /home/1001 路径，就会出错。
- 排查方式：进容器执行
id和cat /proc/1/status | grep Uid，对比两处 UID 是否一致且符合偏移规律 - 修复方向：优先改应用配置（如 MySQL 的
user配置项），其次才考虑在镜像中重建用户并同步调整 home 目录属主 - 绝对避免在镜像中用
USER 0+userns-remap组合，这等于主动放弃隔离价值
真正难处理的不是配置本身，而是那些隐式依赖 UID/GID 的组件：比如 systemd 容器、需要访问 /dev/kmsg 的日志代理、或通过 docker.sock 调用宿主机 Docker API 的 sidecar。它们往往在映射后突然失权，而错误日志里只显示 generic permission denied —— 此时得逐层检查 /proc/PID/status、strace -e trace=chown,setuid,setgid 和宿主机 audit 日志，才能定位到底是哪个 syscall 被拦截了。
