Docker容器root修改挂载代码 主机访问权限报错解决方法

这是Docker bind mount的UID/GID透传机制导致的：容器内用户的UID/GID会直接映射到主机侧，你用容器内root（UID=0）创建/修改的文件，在主机上属主就是root，主机普通用户自然无权限访问，和C++、CMake工具链本身无关。你的核心约束是编译出的二进制必须以root身份运行，只要把「代码编辑/构建动作」和「二进制运行动作」的执行用户拆开，就能同时满足权限互通和程序运行要求，不需要改现有CMake逻辑。

方案1：一劳永逸改镜像启动逻辑（推荐） #

这个方案完全不影响你二进制root运行的要求，同时所有源码、构建产物的权限和主机用户完全匹配，两边随便改不会报错。

1. 先给现有Dockerfile加几行依赖和入口逻辑：

# 安装sudo和权限切换工具，后续用来切root跑程序
RUN apt-get update && apt-get install -y --no-install-recommends sudo && \
    rm -rf /var/lib/apt/lists/*
# 拷贝入口脚本
COPY entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/entrypoint.sh
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

2. 同目录下新建entrypoint.sh，内容如下：

#!/bin/bash
set -e
# 动态创建和主机侧UID/GID完全一致的普通开发用户
groupadd -g "$HOST_GID" devuser 2>/dev/null || true
useradd -u "$HOST_UID" -g "$HOST_GID" -m devuser 2>/dev/null || true
# 给开发用户加免密sudo权限，方便随时切root跑程序
echo "devuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
# 默认切到开发用户进入交互shell，所有改代码、cmake构建操作默认用这个用户
exec su - devuser

3. 重新构建镜像后，启动命令改成把当前主机用户的UID/GID传进容器：

docker run -it --rm -u 0 \
  -e HOST_UID=$(id -u) \
  -e HOST_GID=$(id -g) \
  -v $(pwd):/mnt \
  buildmcu:focal

使用逻辑：

• 进容器后默认是和你主机用户UID完全一致的devuser，这时候你改代码、跑cmake构建，生成的所有文件属主和主机侧完全一致，主机上随便编辑不会有权限问题
• 需要跑必须root权限的二进制时，直接加sudo执行即可，比如sudo ./build/your_mcu_bin，完全满足你程序运行的身份要求。

方案2：不改镜像的临时方案 #

如果不想重新构建镜像，可以保持现有启动命令不变，进容器后不要直接用root操作挂载目录的文件，显式指定和主机同UID的身份执行编辑、构建操作，最后再切root跑二进制：

# 进容器后先执行，把1000:1000换成你主机侧id -u、id -g的实际输出，一般普通用户默认就是1000
# 先把现有挂载目录的属主修正
chown -R 1000:1000 /mnt
# 用匹配主机的身份执行构建
runuser -u 1000 -- cmake -S /mnt -B /mnt/build
runuser -u 1000 -- cmake --build /mnt/build
# 最后直接用root跑二进制，符合要求
/mnt/build/your_mcu_bin

这个方案的缺点是每次操作文件都要加runuser前缀，适合临时调试用。

方案3：临时救急方案（不推荐长期用） #

如果只是临时跑一次不想改任何配置，可以直接在主机侧给项目目录开全局读写权限：

chmod -R 777 /path/to/your/project

这样容器内root生成的文件主机侧普通用户也能改，但缺点是权限配置混乱，还会污染git记录的文件权限位，只适合临时救急，不要在正式开发环境用。

不要图省事直接把Dockerfile的默认运行用户改成UID=1000的普通用户，这样你运行二进制的时候就不是root身份，不符合场景要求。核心逻辑就是把开发操作和程序运行的用户分开，前者匹配主机UID解决权限问题，后者保留root身份满足运行要求。

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