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

Auf meinem lokalen Computer führe ich Folgendes aus:

ssh -X me@remotemachine.com

(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

/Tmp/.X11-unix/X0 existiert also nicht nur, es hat universelle r / w / x-Berechtigungen!

Ich habe zuvor X-Forwarding ohne Problem verwendet, wenn auch 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

Seit ein paar Stunden im Internet herumgesucht, ohne Erfolg. Andere erwähnen das gleiche Problem, aber keine Lösungen.

Wenn Sie einen X - Server läuft und die DISPLAYUmgebungsvariable festgelegt ist :0, die Anwendungen für die Verbindung zum X - Server mit einem Unix - Domain - Socket , die im Allgemeinen unter Linux zu finden ist , sagt in /tmp/.X11-unix/X0(obwohl im Folgenden über die siehe abstrakte Namespace auf den letzten Linux) .

Wenn Sie zur Maschine Remotemachine ssh , wird sshdbei Remotemachine DISPLAY auf localhost:10(zum Beispiel) gesetzt, was diesmal bedeutet, dass X-Verbindungen über TCP zu Port 6010 von machine localhost hergestellt werden. sshd on remotemachine wartet dort auf Verbindungen und leitet eingehende Verbindungen an den ssh-Client weiter. Der ssh-Client versucht dann, eine Verbindung zu /tmp/.X11-unix/X0Ihrem X-Server herzustellen (auf der lokalen Seite, nicht auf der Remote-Seite).

Vielleicht haben Sie keinen 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 strace -e connect xlogoauf Ihrem lokalen Computer einen (oder einen vergleichbaren Pfad auf Ihrem System) ausprobieren, um zu sehen, was eine normale X-Anwendung tut.

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

Auf einem Linux-Debian-Wheezy-Rechner lauscht Xorg sowohl /tmp/.X11-unix/X0im Dateisystem als auch /tmp/.X11-unix/X0im abstrakten Namespace (allgemein geschrieben @/tmp/.X11-unix/X0). Von stracenun an scheinen X11-Anwendungen standardmäßig diesen abstrakten Namespace zu verwenden, was erklärt, warum diese weiterhin funktionieren, wenn sie /tmp/.X11-unixentfernt werden, während sshdieser abstrakte Namespace nicht verwendet wird.

Ich hatte das gleiche Problem mit Cygwin und Xming, die sich mit einem entfernten Linux-Server verbinden.

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

Durch Ändern der Variablen in "localhost: 0.0" wurde das Problem behoben.

export DISPLAY=localhost:0.0

Nachdem ich das getan hatte, funktionierte mein Befehl:

ssh -Yf user@host gvim somefile.c

Dies ergänzt andere Antworten mit Informationen, die spezifisch für Windows-Subsystem für Linux sind. Die akzeptierte Antwort ist richtig: Ihre DISPLAYVariable ist falsch konfiguriert. Es ist jedoch nicht ganz klar, warum dies allein aufgrund dieser Antwort der Fall ist, und deshalb kann ich mit dieser Antwort Abhilfe schaffen.

Wenn Sie cygwin oder Windows-Subsystem für Linux ausführen und Ihr X11-Server auf Windows basiert (z. B. VcXsrvoder XMing), ist es wahrscheinlicher, dass Ihr X11-Server einen TCP-Port überwacht (z. B. 127.0.0.1TCP-Ports 6000-6010) als einen der Standard-Unix-Domain-Socket ( /tmp/.X11-unix/X0). Unix-Sockets werden unter Windows zu diesem Zeitpunkt nicht gut unterstützt, auch nicht innerhalb der WSL. Die Kommunikation zwischen Programmen in einer 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 (z. B. in der Cygwin- oder WSL-Umgebung Ihres Hosts) und Ihre DISPLAYVariable auf den Standardwert (z. B. DISPLAY=:0.0) festgelegt ist, versuchen Anwendungen zunächst, über den Unix-Socket eine Verbindung zum X-Server herzustellen /tmp/.X11-unix/X0. Dies schlägt fehl, aber die meisten Anwendungen greifen dann auf eine TCP-Verbindung zurück localhost, über die der Server erreicht werden kann, vorausgesetzt, Ihr X-Server ist mit Standardeinstellungen konfiguriert.

Sie können dies bestätigen, indem Sie connect()in Verlaufsprotokollen nach Aufrufen aus einer Ausführung 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, sodass dieser Fehler angezeigt wird. sshdDie Verbindung wird zwar an die lokale Seite weitergeleitet, aber die lokale Verbindung des SSH-Clients endet, da der Server nicht über den Unix-Socket erreicht werden kann. Sie erhalten dann den ENOENTFehler.

In solchen Fällen kann das Problem behoben werden, indem Sie Ihre DISPLAYVariable so ändern, dass anstelle der :0.0Syntax die TCP-Syntax verwendet wird :

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

Wie bei 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 zum Initialisierungsskript Ihres Anmelde-Shell-Profils hinzufügen (z ~/.bash_profile. B. ).

Hinweis: Einige Shells haben ein anderes Initialisierungsskript für Anmelde- und Nicht-Anmeldesitzungen. Zum Beispiel könnten Sie mit bash diese Zeile in das Nicht-Anmeldeskript schreiben, dh ~/.bashrcanstelle 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 auf Ihren Host und dann erneut auf einen anderen Host springen würden (wodurch Ihre X11-Weiterleitung verschachtelt würde).

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

Diese Fehlermeldung sagt Ihnen, dass der SSH-Tunnel funktioniert, kann aber nicht herausfinden, wie Sie eine Verbindung zum X-Server auf Ihrer Tunnelseite herstellen .

Früher hat Mac OS X XQuartz für Sie gestartet, aber wir haben dieses nette kleine Feature in der MacOS- Version von Terminal anscheinend aufgegeben .

Ich hatte gerade das gleiche Problem. Das Verwirrende ist, dass auf dem Remote- Computer ein Fehler angezeigt wird, bei dem es sich nicht um eine solche Datei handelt. Diese Datei fehlt jedoch auf dem lokalen (Anzeige-) Computer.

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

mkfifo /tmp/.X11-unix/X0

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

Ich weiß nicht, ob dies relevant ist oder nicht, aber mein Anzeigegerät ist nicht Linux, sondern Windows mit Cygwin und VcXsrv. (Die entfernte Maschine ist Linux)

Ich bin mit dem Windows-Subsystem für Linux auf dieses Problem gestoßen . Das Problem ist, dass ich keine GUI auf dem Client installiert habe, da angenommen 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 diese xclockauf dem Client aus. Wenn Sie die Fehlermeldung erhalten Error: Can't open display: :0, müssen Sie ein GUI-Programm für Windows installieren. Ich habe Xserver benutzt .

Sobald Sie eine GUI installiert haben, versuchen Sie die folgenden Befehle:

export DISPLAY=:0
xclock

Wenn eine Uhr kommt, dann Erfolg!

Versuchen Sie nun, ssh'ing in den Server, dann ausgeführt xclock. 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 festgelegt werden, an die der Server Ihren Computer senden 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-Adresse Ihres Routers angeben und den richtigen Port weiterleiten lassen.

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

Wenn es einwandfrei funktionierte und aus irgendeinem Grund nicht mehr funktionierte, könnte es sich wahrscheinlich um eine unkontrollierte X-Instanz handeln, die im Hintergrund ausgeführt wird. Bitte schließen Sie das mit dem Task-Manager.