Почему моя попытка пересылки 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, то это указывает приложениям подключаться к X-серверу с помощью сокета домена unix, который обычно можно найти в Linux /tmp/.X11-unix/X0(хотя см. Ниже об абстрактном пространстве имен в недавнем Linux) ,

Когда вы используете ssh для удаленной машины , sshdна удаленной машине устанавливается для DISPLAY localhost:10(например,), что на этот раз означает, что X-соединения выполняются через TCP-порт 6010 локального хоста машины. sshd на удаленном компьютере прослушивает соединения и перенаправляет любое входящее соединение клиенту ssh. Затем клиент ssh пытается подключиться /tmp/.X11-unix/X0(на локальном конце, а не на удаленном) к вашему X-серверу.

Теперь, может быть, у вас не работает X-сервер (вы на Mac?), Или, возможно, сокет домена unix не найден в /tmp/.X11-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 была просто ": 0.0" в Cygwin, и хотя она работает локально, она не работала с удаленной командой ssh.

Изменение переменной на «localhost: 0.0» решило проблему.

export DISPLAY=localhost:0.0

Как только я это сделал, моя команда сработала:

ssh -Yf user@host gvim somefile.c

Это дополняет другие ответы информацией, специфичной для Windows-Subsystem for Linux. Общепринятый ответ правилен: ваша DISPLAYпеременная настроена неправильно. Однако не совсем понятно, почему это так, исходя из одного ответа, поэтому я исправляю этот ответ.

Если вы используете Cygwin или Windows-Subsystem для Linux, и ваш сервер X11 работает на базе Windows (например VcXsrv, или XMing), более вероятно, что ваш сервер X11 прослушивает порт TCP (например, 127.0.0.1на портах TCP 6000-6010), чем на сокет домена Unix по умолчанию ( /tmp/.X11-unix/X0). Unix-сокеты не очень хорошо поддерживаются в Windows на данный момент, даже внутри WSL. Взаимодействие между программами в среде, подобной Linux, и программами, работающими непосредственно на хосте Windows, также обычно проще по сравнению с IP-сокетами.

Когда вы запускаете графические приложения локально (например, из среды Cygwin или WSL вашего хоста), и ваша DISPLAYпеременная установлена ​​в значение по умолчанию (т.е. DISPLAY=:0.0), приложения сначала будут пытаться подключиться к X-серверу через сокет Unix /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

Как и в других ответах, вы также можете в интерактивном режиме экспортировать эту переменную из командной строки:

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

Вы также можете сохранить этот параметр более постоянно, добавив эту строку в скрипт инициализации профиля оболочки входа (например ~/.bash_profile).

Примечание. В некоторых оболочках есть разные сценарии инициализации для сеансов входа и не входа в систему. Например, с помощью bash вы можете записать эту строку в сценарий без входа в систему, то есть ~/.bashrcвместо ~/.bash_profile. Если вы это сделаете, будьте осторожны, чтобы не переопределить любое пользовательское значение, которое могло быть установлено ssh. Это было бы так, если бы вы сначала подключились к своему хосту через ssh, а затем снова подключились к другому хосту (таким образом, вложив пересылку X11).

Если ваш дисплейный хост установлен на macOS , убедитесь, что у вас запущен XQuartz .

Это сообщение об ошибке говорит о том, что ssh-туннель работает, но не может понять, как подключиться к X-серверу на вашей стороне туннеля .

В старые добрые времена Mac OS X запускала для вас XQuartz, но мы, очевидно, отказались от этой милой маленькой функции в версии терминала для MacOS .

У меня просто была такая же проблема. Заблуждение состоит в том, что на удаленном компьютере появляется ошибка «нет такого файла» , но на самом деле этот файл отсутствует на локальном (отображаемом) компьютере.

Чтобы посмотреть, что произойдет, я вручную создал отсутствующий файл (на самом деле fifo) на дисплее компьютера, например:

mkfifo /tmp/.X11-unix/X0

Затем снова подключился к удаленной машине, и вот, X11 подключился нормально.

Я не знаю, уместно ли это или нет, но мой дисплей не Linux, а Windows с cygwin и VcXsrv. (Удаленная машина Linux)

Я столкнулся с этой проблемой, используя подсистему Windows для Linux . Проблема в том, что у меня не установлен графический интерфейс на клиенте, так как предполагается, что, поскольку это Windows-машина, у меня есть графический интерфейс.

Чтобы проверить, если у вас есть графический интерфейс, выполните xclockна клиенте. Если вы получили сообщение об ошибке, Error: Can't open display: :0вам нужно установить программу с графическим интерфейсом для Windows. Я использовал Xserver .

После того, как вы установили графический интерфейс, попробуйте следующие команды:

export DISPLAY=:0
xclock

Если появятся часы, значит, удачи!

Теперь попробуйте ssh'ing на сервер, затем запустите xclock. Получили ли вы все еще сообщения об ошибках connect /tmp/.X11-unix/X0: Нет такого файла или каталога Ошибка: Не удается открыть дисплей: localhost: 10.0 ? Это потому, что сервер пытается подключиться к себе, чтобы отобразить графический интерфейс. Вместо этого вы хотите, чтобы в переменной DISPLAY был указан адрес, по которому сервер может получить ваш компьютер. Так что, если он находится в локальной сети, вы просто должны ввести имя вашего компьютера. Если вы подключаетесь к серверу в глобальной сети, вам необходимо указать внешний IP-адрес маршрутизатора и перенаправить соответствующий порт.

LAN: export DISPLAY=ComputerName:0
WAN:export DISPLAY=257.257.257.257:0

Если он работал нормально и перестал работать без какой-либо причины, вероятно, это может быть неконтролируемый экземпляр X, работающий в фоновом режиме. Пожалуйста, закройте это с помощью диспетчера задач.