Linux 在Docker中作为目录装入的单个文件卷

表示可以将单个文件装入Docker容器：

❯ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v /dev/shm:/dev/shm docker
/ # echo "bar" > /dev/shm/foo
/ # docker run --rm -v /dev/shm/foo:/dev/shm/foo ubuntu bash -c 'cat /dev/shm/foo'
bar

-v标志还可用于从主机装载单个文件，而不仅仅是目录

$docker run--rm-it-v~/.bash\u history:/.bash\u history ubuntu/bin/bash

这将把您放入一个新容器中的bash shell中，您将拥有来自主机的bash历史记录，当您退出容器时，主机将拥有在容器中键入的命令的历史记录

但是，当我尝试这样做时，文件将装载为目录：

tom@u ~/project $ docker run --rm -it -v file.json:/file.json test
total 80K
drwxr-xr-x  9 root root 4.0K Dec  7 12:58 .
drwxr-xr-x 63 root root 4.0K Dec  7 12:58 ..
drwxr-xr-x  2 root root 4.0K Dec  4 16:10 file.json

我的Dockerfile如下所示：

FROM ubuntu:14.04
MAINTAINER Tom
CMD ["ls", "-lah", "/test"]

Docker版本是1.9.1，构建a34a1d5

---

这是一个文档问题、我的误解，还是发生了其他事情？

test

是您使用“

docker build-t test

”创建的映像的名称，而不是

/test

文件夹

使用以下内容尝试

Dockerfile

：

CMD ["ls", "-lah", "/"]
or
CMD ["cat", "/file.json"]

以及：

请注意，使用

$（pwd）

装载具有完整绝对路径的文件（不支持相对路径）

通过使用

$（pwd）

，您将获得一个确实存在的绝对路径，并尊重案例，而不是可能不存在的文件名或路径。

---

不存在的主机路径将作为文件夹装入容器。

我花了一些时间在Windows上运行docker来解决和诊断这个问题。这也可能会影响在Mac OSX上运行的用户，因此我在这里为那些可能在这些环境中遇到问题的用户添加了一个答案，因为我的搜索将我带到了这里，并添加了对docker中发生的事情的解释

在Windows或Mac OSX中，docker实际上是在boot2docker VM中运行的，默认情况下，只有用户目录是实际共享的。在Windows上，此用户目录共享为/c/Users/，但是在Docker Machine附带的MinGW shell中，驱动器可以作为/c或/c访问，因此，如果您忘记docker命令实际上是针对boot2docker VM运行的，并且您的文件路径必须存在于boot2docker VM上，并且必须以它们存在的方式指定，那么这可能会让您发疯，因为docker中似乎发生的是，不是给出目录/文件不存在的警告或错误，docker在boot2docker VM中以静默方式创建指定的源作为目录，因此没有现成的输出指示您做了错误的事情

---

因此，如上面的答案所示，如果您的文件作为目录装载，那么请检查您是否提供了绝对路径。对于Windows和Mac OSX，请检查您正在装载的绝对路径是否存在于boot2docker VM中。

以上答案可能已经清楚了。。。但我花了一些时间才弄明白我的情况

导致与-v共享的文件显示为目录而不是文件的根本原因是Docker无法在主机上找到该文件。因此Docker在容器中创建了一个新目录，其名称是主机上不存在的文件的名称，因为Docker认为用户只想共享将来创建的卷/目录

因此，在上面报告的问题中，如果您在-v命令中使用了相对目录，而docker不了解相对目录，这意味着在主机上找不到该文件，因此docker创建了一个目录。上面的答案建议使用$（pwd）将是正确的解决方案，因为问题是由相对目录引起的

但是对于那些没有使用相对目录并且有相同问题的读者来说。。。然后尝试了解主机上缺少该文件的原因

这可能只是一个愚蠢的打字错误

可能是您正在从一个客户端运行“docker run”命令，该客户端在另一台主机上生成docker容器，而共享的文件在该主机上不存在。与-v共享的文件必须存在于docker代理将生成容器的主机上。。。不一定在执行“docker run-v…”命令的客户端上（尽管在许多情况下它们是相同的）

对于Mac和Windows，上面还有其他可能的解释。。。也可能是这样

---

所以主机丢失的文件就是问题所在。。。解决设置中的问题。。。使用$（pwd）可能是解决方案，但并不总是如此。

对于使用VirtualBox机器的人来说，有一个简单的解决方案。

---

默认情况下，会添加C:/User文件夹。如果您的项目位于C:/projects中，请添加此文件夹以使其在VB中可用（具有自动装载功能）。

在docker中运行docker时（例如，通过装载

/var/run/docker.sock），您需要注意，如果您在docker中装载，则使用的文件路径始终是主机上的文件路径

因此，如果在主机上执行以下装载操作：

-v /tmp/foobar.txt:/my/path/foobar.txt

您应该而不是在docker内执行以下装载操作：

-v /my/path/foobar.txt:/my/other/path.txt

但是，请使用主机文件路径，例如：

-v /tmp/foobar.txt:/my/other/path.txt

Docker可能无法找到该文件的情况，即使您确定该文件存在
正如edi9999所指出的，如果您告诉docker守护进程装载一个文件，它将不会查看当前容器的文件系统，而是查看守护进程运行的文件系统

如果您的docker守护进程由于某种原因正在其他地方运行，则可能会出现此问题

❯ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker
/ # echo "bar" > /foo
/ # docker run --rm -v /foo:/foo ubuntu bash -c 'cat foo'
cat: foo: Is a directory

Docker在它的主机上找不到/foo文件，所以它（有用吗？）在那里创建了一个目录，这样至少你已经挂载了一些东西

变通办法
您可以通过将主机目录装入外部容器，然后将该目录用于要显示在内部容器中的卷来解决此问题：

❯ docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v /dev/shm:/dev/shm docker
/ # echo "bar" > /dev/shm/foo
/ # docker run --rm -v /dev/shm/foo:/dev/shm/foo ubuntu bash -c 'cat /dev/shm/foo'
bar

这使得路径
/dev/shm/foo
在任一上下文中引用相同的文件，因此您可以从外部容器引用该文件，并且守护进程将在