it-swarm.com.de

Warum schlägt mein X11-Weiterleitungsversuch mit "connect /tmp/.X11-unix/X0: Keine solche Datei oder kein solches Verzeichnis" fehl?

Auf meinem lokalen Computer starte ich:

ssh -X [email protected]

(Der Vollständigkeit halber habe ich auch alle folgenden mit -Y mit identischen Ergebnissen getestet).

Wie erwartet, greift dies gut auf remotemachine.com zu, und alles scheint gut zu sein. Wenn ich dann jedoch versuche, xcalc auszuführen, erhalte ich:

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

Aber,

$ 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

Es gibt also nicht nur /tmp/.X11-unix/X0, sondern auch universelle R/W/X-Berechtigungen!

Ich habe zuvor X-Forwarding ohne Probleme verwendet, allerdings nicht in einiger Zeit ...

uname -a auf dem Server als Referenz:

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

Ich suche seit ein paar Stunden im Internet, ohne Erfolg. Andere Erwähnungen des gleichen Problems, aber keine Lösungen.

38
John Doucette

Wenn ein X-Server ausgeführt wird und die Umgebungsvariable DISPLAY auf :0 Gesetzt ist, werden Anwendungen angewiesen, über einen Unix-Domain-Socket, der normalerweise unter Linux in zu finden ist, eine Verbindung zum X-Server herzustellen /tmp/.X11-unix/X0 (Siehe unten zum abstrakter Namespace unter neuerem Linux).

Wenn Sie ssh to machine Remotemachine, setzt sshd on Remotemachine DISPLAY auf localhost:10 (Zum Beispiel), was diesmal bedeutet, dass X Verbindungen bestehen Dies erfolgt über TCP an Port 6010 des lokalen Maschinenhosts. sshd on Remotemachine lauscht dort auf Verbindungen und leitet alle eingehenden Verbindungen an den ssh-Client weiter. Der ssh-Client versucht dann, eine Verbindung zu /tmp/.X11-unix/X0 herzustellen (auf der lokalen Seite, nicht auf der Fernbedienung), um Ihren X-Server zu kontaktieren.

Vielleicht läuft jetzt kein X-Server (sind Sie auf einem Mac?) Oder der Unix-Domain-Socket befindet sich nicht in /tmp/.X11-unix, was bedeuten würde, dass ssh beim Kompilieren nicht richtig konfiguriert wurde Zeit.

Um herauszufinden, wie der richtige Pfad für den Unix-Socket lautet, können Sie auf Ihrem lokalen Computer einen strace -e connect xlogo (Oder einen entsprechenden Wert auf Ihrem System) verwenden, um zu sehen, was eine normale X-Anwendung tut.

netstat -x | grep X Kann auch einen Hinweis geben.

Für die Aufzeichnung, auf einem Linux Debian Wheezy-Computer hier, hört Xorg sowohl /tmp/.X11-unix/X0 Im Dateisystem als auch /tmp/.X11-unix/X0 Im abstrakter Namespace (allgemein geschrieben @/tmp/.X11-unix/X0). Ab strace scheinen X11-Anwendungen jetzt standardmäßig diesen abstrakten Namespace zu verwenden, was erklärt, warum diese weiterhin funktionieren, wenn /tmp/.X11-unix Entfernt wird, während ssh diesen abstrakten Namespace nicht verwendet .

25

Ich hatte das gleiche Problem mit Cygwin und Xming, die eine Verbindung zu einem Remote-Linux-Server herstellten.

Meine Variable $ DISPLAY war in Cygwin einfach ": 0.0", und obwohl dies lokal funktioniert, funktionierte es nicht mit dem Befehl remote ssh.

Das Ändern der Variablen in "localhost: 0.0" auf dem lokalen Computer hat das Problem behoben.

export DISPLAY=localhost:0.0

Sobald ich das getan hatte, funktionierte mein Befehl:

ssh -Yf [email protected] gvim somefile.c
45
m0j0

Dies ergänzt andere Antworten mit spezifischen Informationen aus Windows-Subsystem für Linux (WSL). Die akzeptierte Antwort ist korrekt: Ihre Variable DISPLAY ist falsch konfiguriert. Es ist jedoch nicht genau klar, warum dies allein bei dieser Antwort der Fall ist, daher korrigiere ich mit dieser Antwort.

Wenn Sie Cygwin oder Windows-Subsystem für Linux ausführen und Ihr X11-Server Windows-basiert ist (z. B. VcXsrv oder XMing), ist es wahrscheinlicher, dass Ihr X11-Server mithört a TCP Port (wie 127.0.0.1 Port 6000-6010) als auf dem Standard-Unix-Domain-Socket (/tmp/.X11-unix/X0). Unix-Sockets sind nicht in Ordnung -unterstützt unter Windows zu diesem Zeitpunkt, sogar innerhalb der WSL. Die Kommunikation zwischen Programmen in der Linux-ähnlichen Umgebung und Programmen, die direkt auf dem Windows-Host ausgeführt werden, ist im Allgemeinen auch über IP-Sockets einfacher.

Wenn Sie grafische Anwendungen lokal ausführen (dh aus der Cygwin- oder WSL-Umgebung Ihres Hosts) und Ihre Variable DISPLAY auf den Standardwert (dh DISPLAY=:0.0) Festgelegt ist, versuchen Anwendungen zunächst, eine Verbindung herzustellen der X-Server über den Unix-Socket /tmp/.X11-unix/X0. Dies schlägt fehl, aber die meisten Anwendungen greifen dann auf eine TCP -Verbindung auf localhost zurück, die den Server erfolgreich erreichen sollte, vorausgesetzt, Ihr X-Server ist mit Standardeinstellungen konfiguriert.

Sie können bestätigen, dass dies geschieht, indem Sie in Strace-Protokollen nach connect() -Aufrufen aus einem Lauf Ihrer grafischen Anwendung suchen. Diese treten in der Regel früh auf, bevor das Hauptfenster der Anwendung angezeigt wird.

Dieses Fallback-Verhalten tritt nicht auf, wenn ssh eine Verbindung von der Remote-Seite umleitet. Daher wird dieser Fehler angezeigt. sshd auf der Fernbedienung leitet die X11-Verbindung zwar an die lokale Seite weiter, aber die lokale Verbindung des SSH-Clients endet, da der Server nicht über den Unix-Socket erreicht werden kann. Sie erhalten dann den Fehler ENOENT. Die Fallback-Verbindung zu TCP localhost) wird nicht versucht.

In solchen Fällen kann das Problem behoben werden, indem Sie Ihre Variable DISPLAY so ändern, dass anstelle der Syntax :0.0 Die Syntax TCP] verwendet wird:

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

Wie in anderen Antworten erwähnt, können Sie diese Variable auch interaktiv aus Ihrer Shell-Eingabeaufforderung exportieren:

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

Sie können diese Einstellung auch dauerhafter speichern, indem Sie diese Zeile Ihrem Initialisierungsskript für das Shell-Profil hinzufügen (z. B. ~/.bash_profile).

Hinweis: Einige Shells haben ein anderes Initialisierungsskript für Anmelde- und Nicht-Anmeldesitzungen. Mit bash könnten Sie beispielsweise diese Zeile in das Nicht-Login-Skript schreiben, d. H. ~/.bashrc Anstelle von ~/.bash_profile. Wenn Sie dies tun, achten Sie darauf, keinen benutzerdefinierten Wert zu überschreiben, der möglicherweise von ssh festgelegt wurde. Dies wäre der Fall, wenn Sie zuerst über ssh in Ihren Host und dann erneut in einen anderen Host springen würden (wodurch Ihre X11-Weiterleitung verschachtelt würde).

9
init_js

Wenn Ihr Display-Host zufällig macOS ist, stellen Sie sicher, dass XQuartz ausgeführt wird.

Diese Fehlermeldung zeigt an, dass der SSH-Tunnel funktioniert, kann jedoch nicht herausfinden, wie eine Verbindung zum X-Server auf Ihrer Seite des Tunnels hergestellt werden soll.

In den guten alten Zeiten hat Mac OS X XQuartz für Sie gestartet, aber wir haben diese nette kleine Funktion in der macOS Version des Terminals anscheinend aufgegeben.

3
softweyr

Ich hatte gerade das gleiche Problem. Das Verwirrende ist, dass auf dem Computer remote der Fehler "Keine solche Datei" angezeigt wird, diese Datei jedoch auf dem Computer lokal (Anzeige) fehlt.

Um zu sehen, was passieren würde, habe ich die fehlende Datei (eigentlich fifo) manuell auf dem Anzeigegerät wie folgt erstellt:

mkfifo /tmp/.X11-unix/X0

Dann ssh'ed wieder in Remote-Maschine, und siehe da, X11 gut verbunden.

Ich weiß nicht, ob dies relevant ist oder nicht, aber mein Anzeigemaschinen ist nicht Linux, sondern Windows mit Cygwin und VcXsrv. (Die Remote-Maschine ist Linux)

1
smendola

Ich hatte das gleiche Problem mit Cygwin.

Ich habe es gelöst, indem ich angefangen habe, dem * .bat-Skript zu folgen

@echo off

C:
chdir C:\cygwin\bin
run XWin -multiwindow -clipboard -silent-dup-error
run mintty.exe -i /Cygwin-Terminal.ico -

quelle: https://www.asc.tuwien.ac.at/eprog/download/win10_Anleitung.mp4

0
JoKalliauer

Ich bin auf dieses Problem mit dem Windows-Subsystem für Linux gestoßen. Das Problem ist, dass auf dem Client keine GUI installiert war, da davon ausgegangen wird, dass ich eine GUI habe, da es sich um einen Windows-Computer handelt.

Um zu testen, ob Sie eine GUI haben, führen Sie xclock auf dem Client aus. Wenn Sie den Fehler Error: Can't open display: :0 Erhalten, müssen Sie ein GUI-Programm für Windows installieren. Ich habe Xserver verwendet.

Versuchen Sie nach der Installation einer GUI die folgenden Befehle:

export DISPLAY=:0
xclock

Wenn eine Uhr hochkommt, dann Erfolg!

Versuchen Sie nun, auf dem Server zu ssh'en und dann xclock auszuführen. Haben Sie immer noch die Fehlermeldungen erhalten connect /tmp/.X11-unix/X0: Keine solche Datei oder kein solches Verzeichnis Fehler: Anzeige kann nicht geöffnet werden: localhost: 10.0? Dies liegt daran, dass der Server versucht, eine Verbindung zu sich selbst herzustellen, um die GUI anzuzeigen. Stattdessen soll die Variable DISPLAY auf eine Adresse gesetzt werden, an die der Server Ihren Computer beziehen kann. Wenn es sich also in einem LAN befindet, geben Sie einfach den Namen Ihres Computers ein. Wenn Sie eine Verbindung zu einem Server im WAN herstellen, müssen Sie die externe IP Ihres Routers angeben und den richtigen Port weiterleiten lassen.

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

0
Jack Cole

Ich fand, dass in WSL/Ubuntu mein ~/.bashrc die Leitung hatte

$ export DISPLAY=:0

am Ende davon.

Beim Entfernen dieser Zeile und Neustarten der WSL/Ubuntu-App stellte ich fest, dass die Umgebungsvariable DISPLAY korrekt eingestellt war

$ echo $DISPLAY
localhost:0

Jetzt ssh in die Remote-Maschine mit

ssh -X [email protected]

funktioniert und kann Fenster auf dem Remote-Computer öffnen.

0
Jeffery Martin