Dlaczego moja próba przekazania X11 kończy się niepowodzeniem w przypadku „connect /tmp/.X11-unix/X0: Brak takiego pliku lub katalogu”?

Na mojej lokalnej maszynie uruchamiam:

ssh -X me@remotemachine.com

(Dla kompletności przetestowałem również wszystkie poniższe przy użyciu -Y z identycznymi wynikami).

Zgodnie z oczekiwaniami, dostęp do remotemachine.com jest dobry i wszystko wygląda dobrze. Jeśli jednak spróbuję uruchomić xcalc, otrzymam:

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

Ale,

$ 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

Zatem nie tylko /tmp/.X11-unix/X0 istnieje, ale ma uniwersalne uprawnienia r / w / x!

Wcześniej korzystałem z x-forwardingu bez problemu, ale nie za jakiś czas ...

uname -a na serwerze w celach informacyjnych:

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

Szukałem w Internecie od kilku godzin bez powodzenia. Inne wzmianki o tym samym problemie, ale brak rozwiązań.

Jeśli masz uruchomiony serwer X, a DISPLAYzmienna środowiskowa jest ustawiona na :0, to mówi aplikacjom, aby łączyły się z serwerem X za pomocą gniazda domeny unix, które zazwyczaj można znaleźć w systemie Linux w /tmp/.X11-unix/X0(choć poniżej zobacz abstrakcyjną przestrzeń nazw w najnowszym systemie Linux) .

Kiedy ssh do maszyny remotemachine , sshdna remotemachine ustawia DISPLAY na localhost:10(na przykład), co tym razem oznacza, że ​​połączenia X są wykonywane przez TCP z portem 6010 hosta lokalnego komputera. sshd na remotemachine nasłuchuje połączeń tam i przekazuje każde połączenie przychodzące do klienta ssh. Klient ssh następnie próbuje się połączyć /tmp/.X11-unix/X0(na lokalnym, a nie zdalnym), aby skontaktować się z serwerem X.

Może nie masz uruchomionego serwera X (jesteś na komputerze Mac?) Lub może nie można znaleźć gniazda domeny unix w katalogu /tmp/.X11-unix, co oznaczałoby, że ssh nie został poprawnie skonfigurowany podczas kompilacji czas.

Aby dowiedzieć się, jaka jest właściwa ścieżka dla gniazda unix, możesz wypróbować strace -e connect xlogo(lub odpowiednik w systemie) na komputerze lokalnym, aby zobaczyć, co robi normalna aplikacja X.

netstat -x | grep X może również dać wskazówkę.

Dla przypomnienia, na maszynie wheezy z systemem Linux Debian, Xorg nasłuchuje zarówno /tmp/.X11-unix/X0w systemie plików, jak i /tmp/.X11-unix/X0w abstrakcyjnej przestrzeni nazw (ogólnie napisanej @/tmp/.X11-unix/X0). Od straceaplikacje X11 wydają się teraz użyć tej abstrakcyjnej przestrzeni nazw domyślnie, co wyjaśnia, dlaczego te prace, jeśli nadal /tmp/.X11-unixjest usuwany, a sshnie używać tej abstrakcyjnej przestrzeni nazw.

Miałem ten sam problem z Cygwin i Xming, łącząc się ze zdalnym serwerem Linux.

Moja zmienna $ DISPLAY była po prostu „: 0.0” w Cygwin i chociaż działa to lokalnie, nie działała ze zdalnym poleceniem ssh.

Zmiana zmiennej na „localhost: 0.0” rozwiązała problem.

export DISPLAY=localhost:0.0

Gdy to zrobiłem, moje polecenie zadziałało:

ssh -Yf user@host gvim somefile.c

To uzupełnia inne odpowiedzi o informacje specyficzne dla systemu Windows dla podsystemu Linux. Odpowiedź akceptowana jest poprawna: Twój DISPLAYzmienna jest nieprawidłowo skonfigurowana. Jednak nie jest do końca jasne, dlaczego tak jest z samą odpowiedzią, więc naprawiam tę odpowiedź.

Jeśli korzystasz z Cygwina lub podsystemu Windows dla systemu Linux, a Twój serwer X11 jest oparty na systemie Windows (np. VcXsrvLub XMing), bardziej prawdopodobne jest, że Twój serwer X11 nasłuchuje na porcie TCP (na przykład 127.0.0.1na portach TCP 6000-6010) niż na domyślne gniazdo domeny Unix ( /tmp/.X11-unix/X0). Gniazda uniksowe nie są obecnie obsługiwane w systemie Windows, nawet w WSL. Komunikacja między programami w środowisku podobnym do systemu Linux a programami działającymi bezpośrednio na hoście systemu Windows jest również ogólnie łatwiejsza w przypadku gniazd IP.

Kiedy uruchamiasz aplikacje graficzne lokalnie (np. Ze środowiska Cygwin lub WSL twojego hosta), a twoja DISPLAYzmienna jest ustawiona na domyślną (tj. DISPLAY=:0.0), Aplikacje najpierw spróbują połączyć się z serwerem X przez gniazdo Unix /tmp/.X11-unix/X0. To się nie powiedzie, ale większość aplikacji wróci do połączenia TCP localhost, które powinno osiągnąć połączenie z serwerem, zakładając, że Twój serwer X jest skonfigurowany z ustawieniami domyślnymi.

Możesz potwierdzić, że tak się dzieje, szukając connect()połączeń w dziennikach śledzenia z przebiegu aplikacji graficznej. Z reguły miałyby to miejsce wcześnie, zanim pojawi się główne okno aplikacji.

To zachowanie awaryjne nie występuje, gdy ssh przekierowuje połączenie ze strony zdalnej, więc pojawia się ten błąd. sshdfaktycznie przekazuje połączenie do strony lokalnej, ale lokalne połączenia klienta ssh są ślepe, ponieważ nie dociera do serwera przez gniazdo Unix. Otrzymujesz wtedy ENOENTbłąd.

W takich przypadkach zmiana DISPLAYzmiennej na użycie składni TCP zamiast :0.0składni może rozwiązać problem:

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

Jak wspomniano w innych odpowiedziach, można również wyeksportować tę zmienną interaktywnie z wiersza poleceń powłoki:

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

Możesz także zapisać to ustawienie bardziej trwale, dodając tę ​​linię do skryptu inicjującego profil powłoki powłoki (np ~/.bash_profile.).

Uwaga: Niektóre powłoki mają inny skrypt inicjujący dla sesji logowania i bez logowania. Na przykład, dzięki bashowi możesz napisać tę linię do skryptu bez logowania, tj. ~/.bashrcZamiast ~/.bash_profile. Jeśli to zrobisz, uważaj, aby nie przesłonić żadnych wartości niestandardowych, które mogły zostać ustawione przez ssh. Tak byłoby w przypadku, gdy najpierw wskakiwałeś na swój host przez ssh, a następnie ponownie wskakiwałeś na inny host (zagnieżdżając w ten sposób przekazywanie X11).

Jeśli twoim hostem wyświetlania jest MacOS , upewnij się, że masz XQuartz .

Ten komunikat o błędzie informuje, że tunel ssh działa, ale nie może dowiedzieć się, jak połączyć się z serwerem X po swojej stronie tunelu .

W dawnych dobrych czasach Mac OS X uruchamiał dla ciebie XQuartz, ale najwyraźniej zrezygnowaliśmy z tej miłej małej funkcji w wersji terminala macOS .

Właśnie miałem ten sam problem. Mylące jest to, że na komputerze zdalnym pojawia się błąd braku takiego pliku , ale tak naprawdę brakuje tego pliku na komputerze lokalnym (wyświetlającym).

Aby zobaczyć, co się stanie, ręcznie utworzyłem brakujący plik (właściwie fifo) na maszynie wyświetlającej:

mkfifo /tmp/.X11-unix/X0

Następnie ssh'ed ponownie na zdalnej maszynie, a oto X11 dobrze się łączy.

Nie wiem, czy to jest istotne, czy nie, ale moim wyświetlaczem nie jest Linux, to Windows z cygwin i VcXsrv. (Zdalny komputer to Linux)

Wystąpił ten problem przy użyciu podsystemu Windows dla systemu Linux . Problem polega na tym, że nie miałem GUI zainstalowanego na kliencie, ponieważ zakładam, że ponieważ jest to komputer z systemem Windows, mam GUI.

Aby sprawdzić, czy masz GUI, uruchom xclockna kliencie. Jeśli pojawi się błąd Error: Can't open display: :0, musisz zainstalować program GUI dla systemu Windows. Użyłem Xservera .

Po zainstalowaniu GUI wypróbuj następujące polecenia:

export DISPLAY=:0
xclock

Jeśli pojawi się zegar, sukces!

Teraz spróbuj ssh'ing na serwerze, a następnie uruchom xclock. Czy nadal otrzymujesz komunikaty o błędach connect /tmp/.X11-unix/X0: Brak takiego pliku lub katalogu Błąd: Nie można otworzyć wyświetlacza: localhost: 10.0 ? To dlatego, że serwer próbuje się połączyć ze sobą, aby wyświetlić GUI. Zamiast tego chcesz ustawić zmienną DISPLAY na adres, pod którym serwer może uzyskać komputer. Więc jeśli jest w sieci LAN, wystarczy wpisać nazwę swojego komputera. Jeśli łączysz się z serwerem w sieci WAN, musisz określić zewnętrzny adres IP routera i przekazać odpowiedni port.

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

Gdyby działał dobrze i przestał działać bez odpowiedniego powodu, prawdopodobnie mogłaby to być niekontrolowana instancja X działająca w tle. Zamknij to za pomocą menedżera zadań.