如果你想无头运行GUI应用程序，请阅读这里。您需要做的是使用xvfb或其他类似软件创建一个虚拟监视器。如果您想在浏览器上运行Selenium测试，这是非常有用的。

任何地方都没有提到的是，一些软件实际上本身就在Linux容器中使用沙盒。例如，如果你在运行容器时没有使用适当的特权标志，Chrome将永远不会正常运行。

其他的解决方案应该可以工作，但是这里有一个docker-compose的解决方案。

要修复这个错误，您需要将$DISPLAY和. x11 -unix传递给docker，并授予启动docker的用户对xhost的访问权限。

docker-compose之内。yml文件:

version: '2'
services:
    node:
        build: .
        container_name: node
        environment:
            - DISPLAY
        volumes:
            - /tmp/.X11-unix:/tmp/.X11-unix

在终端或脚本中:

xhost + si: localuser: $用户 xhost +当地:码头工人 出口显示= $显示 docker-compose起来

如果你想无头运行GUI应用程序，请阅读这里。您需要做的是使用xvfb或其他类似软件创建一个虚拟监视器。如果您想在浏览器上运行Selenium测试，这是非常有用的。

任何地方都没有提到的是，一些软件实际上本身就在Linux容器中使用沙盒。例如，如果你在运行容器时没有使用适当的特权标志，Chrome将永远不会正常运行。

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/上给出的解决方案似乎是在容器内启动GUI应用程序的一种简单方法(我尝试在ubuntu 14.04上使用firefox)，但我发现需要对作者发布的解决方案进行一个小小的额外更改。

具体来说，对于运行容器，作者已经提到:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    firefox

但我发现(根据同一网站上的一个特定评论)有两个额外的选项

    -v $HOME/.Xauthority:$HOME/.Xauthority

and

    -net=host 

需要在运行容器时指定，以便firefox正常工作:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -v $HOME/.Xauthority:$HOME/.Xauthority \
    -net=host \
    firefox

我已经创建了一个docker映像，其中包含该页面的信息和这些额外的发现:https://hub.docker.com/r/amanral/ubuntu-firefox/

虽然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.

上帝还有另一个解决办法。在容器中运行GUI应用程序，而不使用VNC, SSH和X11转发。这里也提到了。