Mac上的Docker分离内部和外部文件的所有权; 没有这样的Linux
在Mac上运行Docker，使用centos映像，我看到挂载的卷占用了centos（内部）用户的所有权，而在文件系统上，所有权是我的（mdf：mdf）。
在RHEL 7上使用相同的centos映像，我看到装入的卷，但是在内部，在主目录和文件都显示我的uid（1055）。
我可以做一个recursion的chown，例如，insideguy：insideguy，而且看起来都是正确的。 但回到主机文件系统，所有权已经改变为registry中具有与useguid（1001）选定的相同的uid的其他人在执行useradd时。
docker for Linux有一些基本的限制，使得这种情况发生？
作为另一个副作用，在我们的集群中，即使使用sudo权限，也不能在已挂载的文件系统上显示; 只在本地文件系统上。 因此，将docker主目录保存在例如〜/ dockerhome中的愿望失败了，因为docker似乎正在尝试（和失败）执行一些chowns（在Dockerfile或启动脚本中没有描述，所以被假定为 – 体积治疗）。 放置在/ var或/ opt中，适当的所有权，一切顺利。
任何想法两个docker主机之间有什么不同？
细节：OSX 10.11.6; docker v1.12.1 on mac，v1.12.2在RHEL 7上; centos 7
Docker在OS X上有一个基本的限制，就是Docker只能在Linux上运行。
在其他平台上运行Docker时，首先需要设置一个Linux VM（历史上通过VirtualBox，尽pipe最近还有其他选项可用），然后在该VM内运行Docker。
因为Docker是在Linux上本地运行的，所以当你使用像docker run -v /host/path:/container/path这样的东西时，它直接与主机共享文件系统。 因此，如果在容器中运行chown userA somefile并且用户A拥有userid 1001，并且在您的主机上，该用户id属于userB，那么当然当您查看主机上的文件时，它们将显示为由userB拥有。 这里没有魔法; 这只是Unix文件权限的工作方式。 如果您将磁盘或NFS文件系统从一台主机移动到另一台主机，而其本地/etc/passwd文件中存在冲突的条目，则会出现相同的行为。
大多数Docker容器都以root身份运行（或者至less不是本地用户）。 这意味着由Docker中的进程创build的任何文件通常都不会由您拥有，如果您尝试访问不允许此类访问的文件系统，这当然会导致问题。 使用Docker时的select与您在不使用Docker时的select相同：要么确保将容器作为自己的用户标识运行 – 这可能是不可能的，因为许多映像是假定它们将以root身份运行的 – – 或安排将文件存储在其他地方。
这是很多人不鼓励使用主机卷挂载的原因之一，因为这会导致这种混淆（还因为与远程Docker API交互时，远程Docker守护进程没有任何访问权限本地主机文件系统）。
使用Docker for Mac，有一些神奇的文件共享，将本地文件系统暴露给Linux VM（例如，使用VirtualBox，Docker可以使用共享文件夹function）。 这个翻译层可能是你在OS X上关于文件所有权的行为的原因。