我也遇到过类似的问题。我的错误是由于主机的UID和容器用户的UID不匹配造成的。解决方法是将用户的UID作为参数传递给docker build命令，并使用相同的UID创建容器的用户。

在DockerFile中:

ARG UID=1000
ENV USER="ubuntu"
RUN useradd -u $UID -ms /bin/bash $USER

在构建步骤中:

docker build <path/to/Dockerfile> -t <tag/name> --build-arg UID=$UID

在那之后，根据OP运行容器和命令给了我预期的结果。

我通过使用数据容器解决了这个问题。这还具有将数据与应用层隔离的优点。你可以这样运行:

docker run --volumes-from=<container-data-name> ubuntu

本教程很好地解释了数据容器的使用。

在我的情况下，问题就不同了。我不知道为什么，但是即使主机上的一个目录上运行了chmod 777，在Docker容器中它仍然是可见的755。

在容器内部运行sudo chmod 777 my_volume_dir修复了它。

关于Volumes和SELinux的完整故事，请参阅Project Atomic的博客文章。

具体地说:

This got easier recently since Docker finally merged a patch which will be showing up in docker-1.7 (We have been carrying the patch in docker-1.6 on RHEL, CentOS, and Fedora). This patch adds support for "z" and "Z" as options on the volume mounts (-v). For example: docker run -v /var/db:/var/db:z rhel7 /bin/sh Will automatically do the chcon -Rt svirt_sandbox_file_t /var/db described in the man page. Even better, you can use Z. docker run -v /var/db:/var/db:Z rhel7 /bin/sh This will label the content inside the container with the exact MCS label that the container will run with, basically it runs chcon -Rt svirt_sandbox_file_t -l s0:c1,c2 /var/db where s0:c1,c2 differs for each container.

我也遇到过类似的问题。我的错误是由于主机的UID和容器用户的UID不匹配造成的。解决方法是将用户的UID作为参数传递给docker build命令，并使用相同的UID创建容器的用户。

在DockerFile中:

ARG UID=1000
ENV USER="ubuntu"
RUN useradd -u $UID -ms /bin/bash $USER

在构建步骤中:

docker build <path/to/Dockerfile> -t <tag/name> --build-arg UID=$UID

在那之后，根据OP运行容器和命令给了我预期的结果。

从access.redhat.com: Sharing_Data_Across_Containers:

Host volume settings are not portable, since they are host-dependent and might not work on any other machine. For this reason, there is no Dockerfile equivalent for mounting host directories to the container. Also, be aware that the host system has no knowledge of container SELinux policy. Therefore, if SELinux policy is enforced, the mounted host directory is not writable to the container, regardless of the rw setting. Currently, you can work around this by assigning the proper SELinux policy type to the host directory": chcon -Rt svirt_sandbox_file_t host_dir Where host_dir is a path to the directory on host system that is mounted to the container.

这似乎只是一种变通办法，但我试过了，而且奏效了。