你可以允许Docker用户(这里是root)访问X11显示:

XSOCK=/tmp/.X11-unix
xhost +SI:localuser:root 
docker run -t -i --rm -v $XSOCK:$XSOCK:ro -e DISPLAY=unix$(DISPLAY) image 
xhost -SI:localuser:root

虽然Jürgen Weigert的回答基本上涵盖了这个解决方案，但一开始我并不清楚那里描述的是什么。所以我要加上我的看法，以防有人需要澄清。

首先，相关文档是X安全性手册页。

许多在线资料都建议只挂载X11 unix套接字和~/。Xauthority文件放入容器。这些解决方案通常靠运气工作，不需要真正理解为什么，例如容器用户最终与用户拥有相同的UID，因此不需要魔术键授权。

首先，Xauthority文件的模式为0600，因此容器用户将无法读取它，除非它具有相同的UID。

即使您将文件复制到容器中，并更改了所有权，仍然存在另一个问题。如果在主机和容器上使用相同的Xauthority文件运行xauth list，您将看到列出了不同的条目。这是因为xauth根据运行位置筛选条目。

容器中的X客户端(即GUI应用程序)的行为将与xauth相同。换句话说，它看不到用户桌面上运行的X会话的神奇cookie。相反，它会看到您之前打开的所有“远程”X会话的条目(如下所述)。

所以，你需要做的是添加一个新的条目，包含容器的主机名和与主机cookie相同的十六进制键(即在你的桌面上运行的X会话)，例如:

containerhostname/unix:0   MIT-MAGIC-COOKIE-1   <shared hex key>

问题是cookie必须在容器中添加xauth add:

touch ~/.Xauthority
xauth add containerhostname/unix:0 . <shared hex key>

否则，xauth将以一种只能在容器外部看到的方式标记它。

该命令的格式为:

xauth add hostname/$DISPLAY protocol hexkey

在哪里。表示MIT-MAGIC-COOKIE-1协议。

注意:不需要复制或绑定挂载. xauthority到容器中。只需创建一个空白文件，如图所示，并添加cookie。

Jürgen Weigert的答案通过使用FamilyWild连接类型在主机上创建一个新的权限文件并将其复制到容器中来解决这个问题。注意，它首先从~/中提取当前X会话的十六进制键。使用xauth nlist。

所以基本步骤是:

提取用户当前X会话的cookie的十六进制键。 在容器中创建一个新的Xauthority文件，使用容器主机名和共享的十六进制密钥(或创建一个具有FamilyWild连接类型的cookie)。

我承认我不是很了解FamilyWild是如何工作的，也不是很了解xauth或X客户机是如何根据运行位置从Xauthority文件中过滤条目的。欢迎提供这方面的更多信息。

如果你想要分发Docker应用，你需要一个启动脚本来运行容器，该容器为用户的X会话获取十六进制密钥，并以前面解释的两种方式之一将其导入容器。

它还有助于理解授权过程的机制:

在容器中运行的X客户机(即GUI应用程序)在Xauthority文件中查找与容器的主机名和$DISPLAY值匹配的cookie条目。 如果找到匹配的条目，X客户端将其与授权请求一起通过/tmp/. xml目录中的适当套接字传递给X服务器。X11-unix目录挂载在容器中。

注意:X11 Unix套接字仍然需要挂载在容器中，否则容器将没有到X服务器的路由。出于安全原因，大多数发行版默认禁用对X服务器的TCP访问。

为了获得更多信息，并更好地掌握X客户端/服务器关系是如何工作的，查看SSH X转发的示例案例也很有帮助:

The SSH server running on a remote machine emulates its own X server. It sets the value of $DISPLAY in the SSH session to point to its own X server. It uses xauth to create a new cookie for the remote host, and adds it to the Xauthority files for both the local and remote users. When GUI apps are started, they talk to SSH's emulated X server. The SSH server forwards this data back to the SSH client on your local desktop. The local SSH client sends the data to the X server session running on your desktop, as if the SSH client was actually an X client (i.e. GUI app). The X server uses the received data to render the GUI on your desktop. At the start of this exchange, the remote X client also sends an authorization request, using the cookie that was just created. The local X server compares it with its local copy.

OSX (10.13.6, high sierra)

类似于@Nick的答案，但他的解决方案对我不起作用。

首先通过brew install socat安装socat，然后安装XQuartz (https://www.xquartz.org/)

请在评论区(http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/)按照以下步骤进行:

1. in one mac terminal i started:

socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"

2. and in another mac terminal I ran:

docker run -ti --rm \
-e DISPLAY=$(ipconfig getifaddr en0):0 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
firefox

我也可以从我的debian docker容器中启动CLion。

具有BRIDGE网络的Docker。 Ubuntu 16.04使用显示管理器lightdm:

cd /etc/lightdm/lightdm.conf.d
sudo nano user.conf

[Seat:*]
xserver-allow-tcp=true
xserver-command=X -listen tcp

您可以使用更多的私有权限

xhost +

docker run --volume="$HOME/.Xauthority:/root/.Xauthority:rw" --env="DISPLAY=$HOST_IP_IN_BRIDGE_NETWORK:0" --net=bridge $container_name

如果您已经构建了映像，还有另一个答案:

使用sudo调用docker (如何修复docker:获得许可被拒绝的问题) 在主机和容器共享之间共享相同的USER & home & passwd (提示:使用用户id代替用户名) 驱动相关库的dev文件夹工作得很好 加上X11向前。

    docker run --name=CONTAINER_NAME --network=host --privileged \
      -v /dev:/dev \
      -v `echo ~`:/home/${USER} \
      -p 8080:80 \
      --user=`id -u ${USER}` \
      --env="DISPLAY" \
      --volume="/etc/group:/etc/group:ro" \
      --volume="/etc/passwd:/etc/passwd:ro" \
      --volume="/etc/shadow:/etc/shadow:ro" \
      --volume="/etc/sudoers.d:/etc/sudoers.d:ro" \
      --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
      -it REPO:TAG /bin/bash

你可能会问，如果这么多东西都是一样的，那么使用docker还有什么意义呢?嗯，我能想到的一个原因是克服软件包依赖的地狱(https://en.wikipedia.org/wiki/Dependency_hell)。

所以我认为这种用法更适合开发人员。

这里有一个轻量级的解决方案，可以避免在容器上安装任何X服务器，vnc服务器或sshd守护进程。它在简单中得到的好处，却在安全和隔离中失去了。

它假设您使用带有X11转发的ssh连接到主机。

在主机的sshd配置中添加该行

X11UseLocalhost no

因此，主机上转发的X服务器端口在所有接口上都是开放的(不仅仅是lo)，特别是在Docker虚拟接口docker0上。

容器在运行时需要访问. xauthority文件，以便连接到服务器。为此，我们定义了一个只读卷，指向主机上的主目录(可能不是一个明智的主意!)，并相应地设置XAUTHORITY变量。

docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority

这还不够，我们还必须从主机传递DISPLAY变量，但是用ip代替主机名:

-e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")

我们可以定义一个别名:

 alias dockerX11run='docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority -e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")'

然后像这样测试:

dockerX11run centos xeyes