Docker run挂载目录属主为nobody:nogroup无法访问，如何解决？

问题根因 #

该问题是容器与宿主机的UID/GID映射不匹配导致的：

• 你挂载的目录属于宿主机文件系统，若宿主机上该目录对应的UID/GID在容器内无匹配的用户/组，就会显示为nobody/nogroup
• 该目录权限为rwxrws---，仅属主、属组拥有读写执行权限，其余用户无访问权限。若docker开启了用户命名空间（user namespace）隔离，容器内的root默认对应宿主机的非特权用户，自然也无法访问该目录。

解决方案 #

按优先级从高到低提供以下可选项：

方案1：启动容器时指定匹配宿主机的UID/GID（最推荐，无副作用）

1. 先在宿主机执行命令查询目标目录的UID和GID：

stat -c "%u %g" /mnt/disco/projects/ThisProject/

假设返回结果为1000 1000，即UID=1000、GID=1000。
2. 给原docker run命令新增--user和--group-add参数启动容器即可：

docker run -it --rm --gpus all --env CUDA_VISIBLE_DEVICES \
-v "/mnt/disco/projects/ThisProject/:/home/ThisProject/" \
-w "/home/ThisProject/" \
--user 1000:1000 --group-add 1000 \
container_image:latest /bin/bash

该方案不会修改宿主机目录权限，适合公共工作站多用户使用的场景。

方案2：修改宿主机目录权限（仅个人自用工作站可用）

如果是你个人独占的工作站，不需要权限隔离，可以直接在宿主机给目录开放其他用户的访问权限：

# 仅开放当前目录权限
chmod o+rwx /mnt/disco/projects/ThisProject/
# 若需要递归开放目录下所有文件的权限，加-R参数
chmod -R o+rwx /mnt/disco/projects/ThisProject/

该方案操作简单，但会降低目录安全性，公共工作站不建议使用。

方案3：容器内修改目录属主（仅临时使用，会同步修改宿主机目录属性）

如果当前容器已经启动，且容器内root拥有修改挂载目录属性的权限，可以直接在容器内执行：

chown root:root /home/ThisProject

注意该操作会同步修改宿主机上原目录的属主属组，会影响其他用户访问该目录，谨慎使用。

方案4：关闭docker用户命名空间隔离（不推荐，仅测试场景使用）

如果需要容器内root拥有宿主机root的完整权限，可以修改docker daemon配置关闭用户命名空间：

1. 编辑/etc/docker/daemon.json，删除userns-remap相关配置项
2. 执行systemctl restart docker重启docker daemon生效
   该方案会放大容器的权限，有安全隐患，仅建议临时测试使用。

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