在我们的内部测试环境中，我们从基于vSphere的服务器中提供了CentOS虚拟机。图像是香草7.1，带有支持LDAP身份验证的软件包和相关配置。我在xfs文件系统上安装了Docker 1.13.1和OverlayFS驱动程序。
FROM centos:7
RUN useradd dockeruser
USER dockeruser
VOLUME /data
在主机上：
mkdir data
echo "hello from host" > data/host-msg.txt
docker run -ti --rm -v $(pwd)/data:/data testimage bash
集装箱内部：
echo "hello from container" > /data/container-msg.txt
bash: /data/container-msg.txt: Permission denied
列出容器内的目录内容：
drwxr-xr-x 2 12345 13000 25 Feb 12 21:36 data
drwxr-xr-x 5 root root 360 Feb 12 21:36 dev
drwxr-xr-x 1 root root 62 Feb 12 21:36 etc
data目录以uid/gid格式而不是用户名/组名显示所有权。
我已经阅读了许多描述这种行为的文章和问题，以及各种变通策略。
但是。在我当地的Fedora 25开发系统上，我没有这种行为。我执行了上面的过程，能够写入主机装载/数据装载，目录列表显示username/groupname。
/
drwxrwxr-x 2 dockeruser dockeruser 4096 Feb 12 04:36 data
drwxr-xr-x 5 root root 360 Feb 12 22:00 dev
drwxr-xr-x 1 root root 4096 Feb 12 22:00 etc
/data
-rw-rw-r-- 1 dockeruser dockeruser 21 Feb 12 22:04 container-msg.txt
为了使一切尽可能与实验室配置相似，我通过libvirt在我的开发系统上安装了一个CentOS 7.1虚拟机，并再次获得了相同的结果——没有干扰uid/gid映射、用户命名空间，什么都没有。从容器内部写入主机装载的卷Just Worked，开箱即用。
什么可能解释这种行为？实验室虚拟机上的LDAP是否以某种方式在文件系统级别引入了权限问题？有什么具体的事情我可以要求我们的操作团队检查或暂时禁用以尝试解决这个问题吗？
最后，也许也是最重要的一点，如果主机装载卷上的权限问题对我来说根本不是问题，无论是在干净的CentOS还是Fedora工作站上，那么为什么它仍然是Docker社区中的一件事呢？这些设置中是否有一些配置与其他人使用的配置(包括我团队的实验室虚拟机)有根本不同，以至于一切正常？
数据目录以uid/gid格式显示所有权，而不是用户名/组名。
这是因为您的容器没有此uid/guid的映射(check/etc/passwd)。事实上，实际文件的uid/guid总是。返回名称只是应用程序/os的一个功能。尝试从容器内部/外部stat路径。它们应该具有相同的uid/guid
stat /data
stat /path/on/host