为什么我的X11转发尝试失败并显示“ connect /tmp/.X11-unix/X0：没有这样的文件或目录”？

在本地计算机上，我运行：

ssh -X me@remotemachine.com

（为完整起见，我还使用-Y测试了以下所有结果，这些结果相同）。

如预期的那样，可以很好地访问remotemachine.com，并且一切正常。但是，如果我随后尝试运行xcalc，则会得到：

 connect /tmp/.X11-unix/X0: No such file or directory
 Error: Can't open display: localhost:10.0

但，

$ ls -la /tmp/.X11-unix/
total 36
drwxrwxrwt 2 root root  4096 2012-11-23 09:29 .
drwxrwxrwt 8 root root 32768 2012-11-29 08:22 ..
srwxrwxrwx 1 root root     0 2012-11-23 09:29 X0

因此，不仅/tmp/.X11-unix/X0存在，而且具有通用的r / w / x权限！

我以前曾经使用过x-forwarding没问题，尽管在一段时间内没有...

服务器上的uname -a供参考：

Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

现在已经在网上搜索了两个小时，但没有成功。其他提到相同的问题，但没有解决方案。

如果您正在运行X服务器，并且DISPLAY环境变量设置为:0，则会告诉应用程序使用通常在Linux中找到的unix域套接字连接到X服务器/tmp/.X11-unix/X0（尽管有关最新Linux上的抽象名称空间的信息，请参见下文） 。

当您将ssh连接到machine remotemachine时，例如，sshd在remotemachine上将 DISPLAY设置为DISPLAY localhost:10，这意味着X连接是通过TCP完成到计算机localhost的端口6010的。remotemachine上的sshd 侦听那里的连接，并将所有传入的连接转发到ssh客户端。然后，ssh客户端尝试连接/tmp/.X11-unix/X0（在本地端，而不是远程）以联系您的X服务器。

现在，也许您没有运行X服务器（您在Mac上吗？），或者在/tmp/.X11-unix中找不到Unix域套接字，这意味着ssh在编译时未正确配置时间。

要弄清楚unix套接字的正确路径，可以strace -e connect xlogo在本地计算机上尝试一个（或系统上的等效路径）以查看普通X应用程序的作用。

netstat -x | grep X 也可能会提供线索。

根据记录，在Linux Debian的喘息机在这里，Xorg的侦听都/tmp/.X11-unix/X0在文件系统中，并/tmp/.X11-unix/X0在抽象名字空间（一般写@/tmp/.X11-unix/X0）。从开始strace，X11应用程序现在似乎默认情况下使用该抽象名称空间，这解释了为什么如果/tmp/.X11-unix删除了这些名称空间，而仍然ssh不使用该抽象名称空间，为什么它们仍然可以工作。

Cygwin和Xming在连接到远程Linux服务器时也遇到了同样的问题。

我的$ DISPLAY变量在Cygwin中只是“：0.0”，尽管它在本地有效，但不能与远程ssh命令一起使用。

将变量更改为“ localhost：0.0”可解决此问题。

export DISPLAY=localhost:0.0

一旦这样做，我的命令就会起作用：

ssh -Yf user@host gvim somefile.c

这是Windows子系统专用于Linux的信息对其他答案的补充。该接受的答案是正确的：你的DISPLAY变量配置不正确。但是，目前还不清楚，为什么仅从那个答案中就可以解决问题，所以我在用这个答案进行补救。

如果您正在运行cygwin或Linux的Windows子系统，并且您的X11服务器是基于Windows的（例如VcXsrv或XMing），那么您的X11服务器更有可能在TCP端口（例如127.0.0.1TCP端口6000-6010）上侦听。默认的Unix域套接字（/tmp/.X11-unix/X0）。目前，即使在WSL内部，Unix套接字在Windows上也不是很好的支持。通常，通过IP套接字，在类似Linux的环境中的程序与直接在Windows主机上运行的程序之间进行通信也更容易。

当您在本地运行图形应用程序时（即从主机的Cygwin或WSL环境运行），并且将DISPLAY变量设置为默认值（即DISPLAY=:0.0），应用程序将首先尝试通过Unix socket连接到X服务器/tmp/.X11-unix/X0。这将失败，但是大多数应用程序将回退到上的TCP连接localhost，前提是您的X服务器配置了默认设置，它将成功到达服务器。

您可以通过connect()从图形应用程序的运行中查找strace日志中的调用来确认是否正在发生这种情况。这些通常会在应用程序主窗口出现之前的早期发生。

当ssh从远程侧重定向连接时，不会发生这种回退行为，因此您会收到该错误。sshd确实将连接转发到本地，但是ssh客户端的本地连接死胡同，因为它无法通过Unix套接字到达服务器。您然后得到ENOENT错误。

在这种情况下，将DISPLAY变量更改为使用TCP语法而不是:0.0语法可以解决此问题：

DISPLAY=127.0.0.1:0 ssh remote some-gui-application

像提到的其他答案一样，您也可以从shell提示符以交互方式导出该变量：

$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application

您还可以通过将该行添加到登录Shell配置文件初始化脚本（例如~/.bash_profile）中来更永久地存储此设置。

注意：某些Shell对于登录和非登录会话具有不同的初始化脚本。例如，使用bash可以将该行写入非登录脚本，即~/.bashrc，而不是~/.bash_profile。如果这样做，请注意不要覆盖ssh可能设置的任何自定义值。如果您先通过ssh跳入主机，然后又跳入另一台主机（因此嵌套了X11转发），就会是这种情况。

如果您的显示主机恰好是macOS，请确保您正在运行XQuartz。

此错误消息告诉您ssh隧道正在工作，但无法确定如何连接到隧道一侧的X服务器。

在过去的好日子里，Mac OS X曾经为您启动XQuartz，但是我们显然已经放弃了macOS版本的终端中的这个不错的小功能。

我只是有同样的问题。令人困惑的是，您在远程计算机上收到no-such-file错误，但实际上在本地（显示）计算机上缺少此文件。

为了看看会发生什么，我在显示机器上手动创建了丢失的文件（实际上是fifo），如下所示：

mkfifo /tmp/.X11-unix/X0

然后，再次将其切换到远程计算机中，瞧，X11连接正常。

我不知道这是否相关，但是我的显示机器不是Linux，而是cygwin和VcXsrv的Windows。（远程机器是Linux）

我使用Linux的Windows子系统遇到了这个问题。问题是我没有在客户端上安装GUI，因为假设这是Windows计算机，所以我有GUI。

要测试您是否具有GUI，请xclock在客户端上执行。如果收到错误，Error: Can't open display: :0则需要为Windows安装GUI程序。我使用Xserver。

一旦安装了GUI，请尝试以下命令：

export DISPLAY=:0
xclock

如果时钟来了，那就成功了！

现在尝试将ssh'插入服务器，然后运行xclock。您是否仍然得到错误消息connect /tmp/.X11-unix/X0：没有这样的文件或目录错误：无法打开显示：localhost：10.0？那是因为服务器试图连接到自身以显示GUI。相反，您希望将DISPLAY变量设置为服务器可以在其中获取计算机的地址。因此，如果它在LAN上，则只需输入计算机的名称即可。如果要连接到WAN上的服务器，则需要指定路由器的外部IP并转发正确的端口。

局域网：export DISPLAY=ComputerName:0
WAN：export DISPLAY=257.257.257.257:0

如果它工作正常并且在没有任何适当原因的情况下停止工作，则可能是在后台运行的不受控制的X实例。请使用任务管理器将其关闭。