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

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

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

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

这是:

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

尝试docker卷创建。

mkdir -p /data1/Downloads
docker volume create --driver local --name hello --opt type=none --opt device=/data1/Downloads --opt o=uid=root,gid=root --opt o=bind
docker run -i -v hello:/Downloads ubuntu bash

看一下创建的文档docker卷。

这个问题是因为在您的机器上启用了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

关于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/GID不能根据主机上文件的UID/GID权限访问该文件。然而，这一具体情况有所不同。

权限字符串末尾的点，drwxr-xr-x。，表示配置了SELinux。在SELinux中使用主机挂载时，您需要将一个额外的选项传递到卷定义的末尾:

z选项表示绑定挂载内容在多个容器之间共享。 Z选项表示绑定挂载内容是私有的、非共享的。

你的卷挂载命令看起来像这样:

sudo docker run -i -v /data1/Downloads:/Downloads:z ubuntu bash

有关使用SELinux的主机挂载的更多信息，请参见配置SELinux标签。

对于以不同用户运行容器时遇到此问题的其他人，您需要确保容器内用户的UID/GID对主机上的文件具有权限。在生产服务器上，这通常是通过在映像构建过程中控制UID/GID来实现的，以匹配能够访问文件的主机上的UID/GID(或者更好的是，在生产中不使用主机挂载)。

命名卷通常优于主机挂载，因为它将从映像目录初始化卷目录，包括任何文件所有权和权限。这种情况发生在卷为空且容器是用命名卷创建的情况下。

macOS用户现在有OSXFS自动处理Mac主机和容器之间的UID/ gid。它不能帮助的一个地方是来自嵌入式虚拟机内部被挂载到容器中的文件，比如/var/lib/docker.sock。

对于每个开发人员都可能更改主机UID/GID的开发环境，我的首选解决方案是启动容器时使用一个以root身份运行的入口点，在容器中固定用户的UID/GID以匹配主机卷UID/GID，然后使用gosu从根删除到容器用户，以便在容器中运行应用程序。这个重要的脚本是我的基本映像脚本中的fix-perms，可以在:Docker base Images from Brandon Mitchell找到

fix-perms脚本的重要部分是:

# Update the UID
if [ -n "$opt_u" ]; then
  OLD_UID=$(getent passwd "${opt_u}" | cut -f3 -d:)
  NEW_UID=$(stat -c "%u" "$1")
  if [ "$OLD_UID" != "$NEW_UID" ]; then
    echo "Changing UID of $opt_u from $OLD_UID to $NEW_UID"
    usermod -u "$NEW_UID" -o "$opt_u"
    if [ -n "$opt_r" ]; then
      find / -xdev -user "$OLD_UID" -exec chown -h "$opt_u" {} \;
    fi
  fi
fi

这将获得容器内用户的UID和文件的UID，如果不匹配，则调用usermod来调整UID。最后，它进行递归查找以修复没有更改uid的任何文件。比起运行带有-u $(id -u):$(id -g)标志的容器，我更喜欢这样做，因为上面的入口点代码不需要每个开发人员运行脚本来启动容器，并且卷之外的任何由用户拥有的文件都将更正其权限。

您还可以让Docker通过使用一个执行绑定挂载的命名卷来从映像初始化一个主机目录。这个目录必须已经存在，并且您需要提供到主机目录的绝对路径，而不像组合文件中的主机卷可以是相对路径。该目录也必须为空，以便Docker对其进行初始化。定义命名卷到绑定挂载的三个不同选项如下:

  # create the volume in advance
  $ docker volume create --driver local \
      --opt type=none \
      --opt device=/home/user/test \
      --opt o=bind \
      test_vol

  # create on the fly with --mount
  $ docker run -it --rm \
    --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=none,volume-opt=o=bind,volume-opt=device=/home/user/test \
    foo

  # inside a docker-compose file
  ...
  volumes:
    bind-test:
      driver: local
      driver_opts:
        type: none
        o: bind
        device: /home/user/test
  ...

最后，如果尝试使用用户名称空间，您将发现主机卷存在权限问题，因为容器的UID/ gid发生了移位。在这种情况下，可能最容易避免使用主机卷，而只使用命名卷。