从本地到容器的docker cp得到了奇怪的用户组

Question

我开始从docker run --name postgres -e POSTGRES_PASSWORD=passwd -d postgres提取最新的官方postgres docker镜像

然后我正在运行以下命令docker cp colors.csv postgres:/colors.csv。

但是在docker cp之后，复制的文件是在一个奇怪的用户组中创建的，而不是root用户。

xuanyue$ docker exec -it postgres ls -ahl
total 80K
drwxr-xr-x   1 root      root      4.0K Jul 16 18:54 .
drwxr-xr-x   1 root      root      4.0K Jul 16 18:54 ..
drwxr-xr-x   1 root      root      4.0K Jul  2 23:39 bin
drwxr-xr-x   2 root      root      4.0K Feb 23 23:23 boot
-rwxrwxrwx   1 120042327 120042327  251 Jul 16 18:38 colors.csv

那是为什么？我知道我可以通过chown轻松更改它，但是很好奇

Answer 1

这是一个相当令人不安的行为，因为与docker cp in the docs的描述相比，结果是出乎意料的：

  

cp命令的行为类似于Unix cp -a命令，因为如果可能，将以递归方式复制目录并保留权限。所有权设置为目的地的用户和主要组。例如，使用根用户的UID:GID创建复制到容器的文件。复制到本地计算机上的文件是由调用UID:GID命令的用户的docker cp创建的。但是，如果您指定-a选项，则docker cp将所有权设置为源用户和主要组。

但是我发现许多与此行为相关的未解决问题/ PR：

• docker cp behavior changed
• docker cp is not setting the right UID & GID to the destination file
• Change uid/gid on docker cp and preserve it on docker cp -a

我认为这将在Docker的未来版本中进行修补；等待该操作，您必须假定将文件复制到容器后保留本地文件的UID:GID。在您的示例中，colors.csv可能在主机上有UID=120042327和GID=120042327（请在主机上与stat colors.csv进行检查），这就是为什么在容器中得到此结果的原因。此外，在这里，120042327与容器中的任何用户/组都不匹配，但是如果是这种情况，您可能已经看到拥有该文件的一些奇怪的用户/组（与120042327用户相对应的用户/组/ group）。