Чому моя спроба переадресації 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-переадресацію, хоча не через якийсь час ...

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

Коли ви SSH до машини remotemachine , sshdна remotemachine набори DISPLAY для localhost:10(наприклад), що на цей раз означає , що X з'єднання дійсно бути зроблено через TCP порт 6010 машинно локального хоста. sshd на remotemachine прослуховує з'єднання там і пересилає будь-яке вхідне з'єднання з 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-підсистеми для Linux. Загальноприйнятий відповідь правильний: ваша DISPLAYзмінна налаштована неправильно. Однак не зовсім зрозуміло, чому так відбувається саме з цієї відповіді, тому я виправляю цю відповідь.

Якщо ви працюєте з cygwin або Windows-підсистемою для Linux, а ваш сервер X11 базується на вікнах (наприклад 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()дзвінки в журналах прострочок із запуску вашої графічної програми. Це, як правило, відбудеться рано, перш ніж з’явиться головне вікно програми.

Така резервна поведінка не відбувається, коли 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 .

У мене просто була така ж проблема. Заплутаною річчю є те, що ви отримуєте помилку no-such-file на віддаленій машині, але насправді цей файл відсутній на локальній (дисплейній) машині.

Щоб побачити, що станеться, я вручну створив на дисплейній машині файл, що відсутній (фактично), наприклад:

mkfifo /tmp/.X11-unix/X0

Потім знову ssh'ed у віддалену машину, і ось, ось X11 добре підключений.

Я не знаю, чи це актуально чи ні, але мій дисплей не Linux, це Windows з cygwin та VcXsrv. (Віддалена машина - Linux)

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

Щоб перевірити, чи є у вас графічний інтерфейс, виконайте його xclockна клієнті. Якщо ви отримаєте помилку, Error: Can't open display: :0вам потрібно встановити програму GUI для Windows. Я використовував Xserver .

Після встановлення графічного інтерфейсу спробуйте виконати наступні команди:

export DISPLAY=:0
xclock

Якщо з'явиться годинник, то успіх!

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

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

Якщо він працював нормально і перестав працювати без будь-яких належних причин, ймовірно, це може бути неконтрольований X екземпляр, що працює у фоновому режимі. Закрийте це, використовуючи диспетчер завдань.