Question

在我们的内部测试环境中，我们从基于vSphere的服务器中配置CentOS VM。这些图像是带有包和相关配置的vanilla 7.1，以支持通过LDAP进行身份验证。我在xfs文件系统上安装了带有OverlayFS驱动程序的Docker 1.13.1。

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格式显示所有权，而不是用户名/组名。

我已阅读许多描述此行为的文章和问题，并various strategies向workaround阅读。

但即可。在我当地的Fedora 25开发系统中，我没有这种行为。我执行上面的过程，能够写入主机挂载/数据挂载，目录列表显示用户名/组名。

/
    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 VM，并再次得到了相同的结果 - 没有弄乱uid / gid映射，用户命名空间，什么都没有。从容器内部写入主机安装的卷Just Worked，开箱即用。

有什么可能解释这种行为？实验室VM上的LDAP是否以某种方式在文件系统级别引入权限问题？有什么具体的东西我可以要求我们的运营团队检查或暂时禁用以尝试解决此问题吗？

最后也许是最重要的一点，如果在主机安装的卷上的权限问题对于我来说在一个干净的CentOS或Fedora工作站上似乎根本不是问题那么为什么它仍然是Docker社区中的一个问题？这些设置中是否有一些配置与其他人使用的配置（包括我的团队的实验室虚拟机）根本不同，事情才有效？

Answer 1

数据目录以uid / gid格式显示所有权，而不是用户名/组名。

这是因为你的容器没有这个uid / guid的映射（检查/ etc / passwd）。实际上，实际文件中的uid / guid 总是。它只是应用程序/操作系统的一个功能，可以返回名称。尝试stat来自容器内部/外部的路径。他们应该有相同的uid / guid

stat /data
stat /path/on/host

Docker主机安装的卷权限

1 个答案: