在Mac上运行docker，带有centos图像，我看到已安装的卷承担了centos（内部）用户的所有权，而在文件系统上，所有权是我的（mdf：mdf）。
在RHEL 7上使用相同的centos图像，我看到已安装的卷，但在内部，在centos中，主目录和文件都显示我的uid（1055）。
我可以做一个递归的chown，例如，insideguy：insideguy，所有看起来都正确。但回到主机文件系统中，所有权已更改为注册表中的其他人，其具有与执行useradd时为insideguy（1001）选择的uid相同的uid。
Linux版本的docker是否存在一些基本限制？
另一个副作用是，在我们的集群中，即使使用sudo权限，也无法在已安装的文件系统上进行chown;仅在本地文件系统上。所以将docker主目录保存在例如〜/ dockerhome中的愿望失败了，因为docker似乎正在尝试（并且失败）执行一些chowns（在Dockerfile或start脚本中没有描述，所以假设它们是 - 体积治疗）。在/ var或/ opt中放置适当的所有权，一切顺利。
知道两个docker主机之间有什么不同吗？
细节：OSX 10.11.6; docker v1.12.1 on mac，v1.12.2 on RHEL 7; centos 7
答案 0 :(得分：3)
OS X上的Docker存在一个基本限制：这就是Docker只能在Linux上运行的事实。
在其他平台上运行Docker时，首先需要设置Linux VM（历史上通过VirtualBox，尽管最近有其他选项可用），然后在该VM中运行Docker。
由于Docker在Linux上本机运行，因此当您使用docker run -v /host/path:/container/path之类的东西时，它会直接与主机共享文件系统。因此，如果在容器内部运行chown userA somefile并且用户A具有用户ID 1001，并且在您的主机上该用户ID属于userB，那么当您查看主机上的文件时，它们看起来将由userB拥有。这里没有魔力;这就是Unix文件权限的工作原理。例如，如果您要将磁盘或NFS文件系统从一个主机移动到另一个主机/etc/passwd文件中存在冲突条目的主机，则会出现相同的行为。
大多数Docker容器都以root（或至少不是您的本地用户）运行。这意味着由Docker中的进程创建的任何文件通常不都归您所有，如果您尝试访问不允许此类访问的文件系统，这当然会导致问题。您在使用Docker时的选择与不使用Docker时的选择完全相同：要么确保您将容器作为您自己的用户ID运行 - 这可能是不可能的，因为许多映像是在假设它们将以root身份运行的情况下构建的 - - 或安排在其他地方存储文件。
这是许多人不鼓励使用主机卷挂载的原因之一，因为它可能导致这种混淆（并且还因为在与远程Docker API交互时，远程Docker守护程序不会拥有对本地主机文件系统的任何访问权限。）
使用Docker for Mac，有一些神奇的文件共享可以将本地文件系统暴露给Linux VM（例如，使用VirtualBox，Docker可以使用shared folders功能）。此转换层可能是您在OS X上记录的与文件所有权相关的行为的原因。