核心思路是让容器内进程uid与宿主机挂载目录所有者uid数值一致；需先用id -u/-g和ls -ld确认冲突，再通过chown -r匹配属主、构建自定义镜像预设用户或适配userns-remap映射偏移来解决。
核心思路是让容器内进程的 UID 与宿主机挂载目录的实际所有者 UID 数值一致——Linux 权限系统只认数字，不认用户名。
确认冲突源头
先定位问题是否真是 UID 不匹配引发的锁死：
- 进容器查真实运行身份：
docker exec -it your-runner id -u -g，记下输出的 UID 和 GID（如 998 998） - 在宿主机查挂载目录归属：
ls -ld /opt/gitlab-runner/config /opt/gitlab-runner/cache，看 owner 是否为同一数字（比如显示 1000 1000 就不匹配） - 若 UID/GID 不一致，且日志出现
Permission denied、cannot open lock file或写入失败，基本可锁定为 UID 冲突
推荐方案：宿主机侧主动适配
最直接、低风险、无需改镜像的方式，适合开发和 CI/CD 环境：
- 把挂载目录属主改为容器实际 UID：
sudo chown -R 998:998 /opt/gitlab-runner/config /opt/gitlab-runner/cache - 确保目录权限允许该 UID 写入：
sudo chmod -R u+rw /opt/gitlab-runner/config /opt/gitlab-runner/cache - 重启 Runner 容器后验证：
docker exec -it gitlab-runner ls -l /etc/gitlab-runner，应能正常列出且无报错
长期方案：构建 UID 可控的镜像
避免每次部署都手动调权限，适合生产环境统一管理：
- 在 Dockerfile 中显式创建 UID 匹配宿主机用户的账号：
RUN useradd -u 1000 -m appuser && usermod -aG wheel appuser - 用
USER appuser指定运行身份，而非依赖镜像默认 UID - 构建时可通过构建参数动态注入 UID：
docker build --build-arg UID=1000 -t my-runner .，Dockerfile 中用ARG UID接收
进阶注意：开启 user-namespace 时的映射偏移
如果 Docker 启用了 user-namespace remap（检查 /etc/docker/daemon.json 是否含 "userns-remap"），UID 不再直通宿主机：
- 查映射范围：
cat /etc/subuid，常见为dockremap:100000:65536 - 此时容器内指定
--user 998:998，实际对应宿主机 UID100000 + 998 = 100998 - 宿主机目录必须由该映射后 UID 拥有：
sudo chown -R 100998:100998 /path - 否则建议临时禁用 userns-remap 测试，或改用命名卷（Docker 自动处理属主）
