我验证了chcon -Rt svirt_sandbox_file_t /path/to/volume可以工作，并且您不必作为特权容器运行。

这是:

Docker版本0.11.1-dev, build 02d20af/0.11.1 CentOS 7作为主机和容器，并启用SELinux。

这个问题是因为在您的机器上启用了SELinux。检查下面并禁用它。

[root@nfs-server ~]# getenforce
Enforcing
[root@nfs-server ~]# setenforce 0
[root@nfs-server ~]# getenforce
Permissive

如果你只是想禁用SELinux，你可以使用——security-opt标签:disable标志来做到这一点。

docker run --security-opt label:disable -v /run/docker.sock:/run/docker.sock POWERFULLCONTAINER

我也遇到过类似的问题。我的错误是由于主机的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运行容器和命令给了我预期的结果。

关于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.

警告:此解决方案存在安全风险。

尝试以特权模式运行容器:

sudo docker run --privileged=true -i -v /data1/Downloads:/Downloads ubuntu bash

另一种选择(我没有尝试过)是创建一个特权容器，然后在其中创建非特权容器。

这是SELinux的问题。

你可以临时发行

su -c "setenforce 0"

在主机上访问或通过运行添加SELinux规则

chcon -Rt svirt_sandbox_file_t /path/to/volume