Pourquoi ma tentative de transfert X11 échoue-t-elle avec "connect /tmp/.X11-unix/X0: Aucun fichier ou répertoire de ce type"?
Sur ma machine locale, je lance:
ssh -X [email protected]
(Pour être complet, j'ai également testé tous les éléments suivants en utilisant -Y avec des résultats identiques).
Comme prévu, cela accède à remotemachine.com très bien, et tout semble bien. Cependant, si j'essaie d'exécuter xcalc, j'obtiens:
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0
Mais,
$ 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
Donc non seulement /tmp/.X11-unix/X0 existe, mais il a des autorisations universelles r/w/x!
J'ai déjà utilisé x-forwarding sans problème, mais pas depuis un certain temps ...
uname -a sur le serveur pour référence:
Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux
Cherche autour du Web depuis quelques heures sans succès. Autres mentions du même problème, mais pas de solutions.
Si un serveur X est en cours d'exécution et que la variable d'environnement DISPLAY est définie sur :0, qui indique aux applications de se connecter au serveur X à l'aide d'une socket de domaine unix qui se trouve généralement sous Linux dans /tmp/.X11-unix/X0 (bien que voir ci-dessous sur le espace de noms abstrait sur Linux récent).
Lorsque vous SSH pour machine remotemachine, sshd on remotemachine définit DISPLAY sur localhost:10 (par exemple), ce qui signifie cette fois que les connexions X sont effectuées via TCP vers le port 6010 de la machine localhost. sshd on remotemachine écoute les connexions sur et transfère toute connexion entrante au client ssh. Le client ssh essaie ensuite de se connecter à /tmp/.X11-unix/X0 (sur l'extrémité locale, pas sur la télécommande) pour contacter votre serveur X.
Maintenant, peut-être que vous n'avez pas de serveur X en cours d'exécution (êtes-vous sur Mac?) Ou peut-être que la socket de domaine unix ne se trouve pas dans /tmp/.X11-unix, ce qui signifierait que ssh n'a pas été correctement configuré lors de la compilation temps.
Pour savoir quel est le chemin approprié pour le socket unix, vous pouvez essayer un strace -e connect xlogo (ou l'équivalent sur votre système) sur votre ordinateur local pour voir ce que fait une application X normale.
netstat -x | grep X peut également donner un indice.
Pour mémoire, sur une machine Linux Debian Wheezy ici, Xorg écoute à la fois /tmp/.X11-unix/X0 dans le système de fichiers et /tmp/.X11-unix/X0 sur espace de noms abstrait (généralement écrit @/tmp/.X11-unix/X0). Depuis strace, les applications X11 semblent désormais utiliser cet espace de noms abstrait par défaut, ce qui explique pourquoi celles-ci fonctionnent toujours si /tmp/.X11-unix est supprimé, tandis que ssh n'utilise pas cet espace de noms abstrait.
J'ai eu le même problème avec Cygwin et Xming, en me connectant à un serveur Linux distant.
Ma variable $ DISPLAY était simplement ": 0.0" dans Cygwin, et bien que cela fonctionne localement, elle ne fonctionnait pas avec la commande ssh distante.
Changer la variable en "localhost: 0.0" sur la machine locale a résolu le problème.
export DISPLAY=localhost:0.0
Une fois que j'ai fait cela, ma commande a fonctionné:
ssh -Yf user@Host gvim somefile.c
Ceci complète d'autres réponses avec des informations spécifiques du sous-système Windows pour Linux (WSL). La réponse acceptée est correcte: votre variable DISPLAY est mal configurée. Cependant, on ne sait pas exactement pourquoi c'est le cas de cette seule réponse, donc je corrige cette réponse.
Si vous exécutez cygwin ou Windows-Subsystem for Linux et que votre serveur X11 est basé sur Windows (par exemple VcXsrv ou XMing), il est plus probable que votre serveur X11 écoute un TCP (tel que 127.0.0.1 port 6000-6010) que sur le socket de domaine Unix par défaut (/tmp/.X11-unix/X0). Les sockets Unix ne sont pas bien - pris en charge sur Windows à ce stade, même à l'intérieur de WSL.La communication entre les programmes dans l'environnement de type Linux et les programmes s'exécutant directement sur l'hôte Windows est également généralement plus facile sur les sockets IP.
Lorsque vous exécutez des applications graphiques localement (c'est-à-dire à partir de l'environnement Cygwin ou WSL de votre hôte) et que votre variable DISPLAY est définie sur la valeur par défaut (c'est-à-dire DISPLAY=:0.0), Les applications tenteront d'abord de se connecter à le serveur X via le socket Unix /tmp/.X11-unix/X0. Cela échouera, mais la plupart des applications se replieront alors sur une connexion TCP sur localhost, qui devrait réussir à atteindre le serveur, en supposant que votre serveur X est configuré avec des valeurs par défaut.
Vous pouvez confirmer que cela se produit en recherchant les appels connect() dans les journaux de strace à partir d'une exécution de votre application graphique. Celles-ci se produisent généralement tôt, avant que la fenêtre principale de l'application n'apparaisse.
Ce comportement de secours ne se produit pas lorsque ssh redirige une connexion depuis le côté distant, vous obtenez donc cette erreur. sshd sur la télécommande transmettra en effet la connexion X11 au côté local, mais les impasses de connexion locale du client ssh car il ne parvient pas à atteindre le serveur via le socket Unix. Vous obtenez alors l'erreur ENOENT. Il n'essaye pas la connexion de secours à TCP localhost.
Dans de tels cas, la modification de votre variable DISPLAY pour utiliser la syntaxe TCP au lieu de la syntaxe :0.0) Peut résoudre le problème:
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
Comme d'autres réponses le mentionnent, vous pouvez également exporter cette variable de manière interactive à partir de votre invite de shell:
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
Vous pouvez également stocker ce paramètre de manière plus permanente en ajoutant cette ligne à votre script d'initialisation de profil Shell de connexion (par exemple ~/.bash_profile).
Remarque: Certains shells ont un script d'initialisation différent pour les sessions de connexion et de non-connexion. Par exemple, avec bash, vous pouvez écrire cette ligne dans le script sans connexion, c'est-à-dire ~/.bashrc, Au lieu de ~/.bash_profile. Si vous le faites, veillez à ne pas remplacer toute valeur personnalisée qui aurait pu être définie par ssh. Ce serait le cas si vous sautiez d'abord dans votre hôte via ssh, puis de nouveau dans un autre hôte (imbriquant ainsi votre transfert X11).
Si votre hôte d'affichage se trouve être macOS, assurez-vous que XQuartz est en cours d'exécution.
Ce message d'erreur vous indique que le tunnel ssh fonctionne, mais il ne peut pas comprendre comment se connecter au serveur X sur de votre côté du tunnel .
Au bon vieux temps, Mac OS X utilisé pour démarrer XQuartz pour vous, mais nous avons apparemment abandonné cette jolie petite fonctionnalité dans le version macOS du terminal.
J'ai juste eu le même problème. La chose déroutante est que vous obtenez l'erreur no-such-file sur la machine distante, mais en fait ce fichier est manquant sur la machine locale (affichage).
Juste pour voir ce qui se passerait, j'ai créé manuellement le fichier manquant (fifo, en fait), sur la machine d'affichage, comme ceci:
mkfifo /tmp/.X11-unix/X0
Puis ssh'ed à nouveau dans la machine distante, et voilà, le X11 s'est bien connecté.
Je ne sais pas si cela est pertinent ou non, mais ma machine d'affichage n'est pas Linux, c'est Windows avec cygwin et VcXsrv. (La machine distante est Linux)
J'ai eu le même problème avec cygwin.
Je l'ai résolu en commençant à suivre * .bat-script
@echo off
C:
chdir C:\cygwin\bin
run XWin -multiwindow -clipboard -silent-dup-error
run mintty.exe -i /Cygwin-Terminal.ico -
source: https://www.asc.tuwien.ac.at/eprog/download/win10_Anleitung.mp4
J'ai rencontré ce problème en utilisant le sous-système Windows pour Linux . Le problème est que je n'avais pas d'interface graphique installée sur le client, en raison de l'hypothèse que puisque c'est une machine Windows, j'ai une interface graphique.
Pour tester si vous avez une interface graphique, exécutez xclock sur le client. Si vous obtenez l'erreur Error: Can't open display: :0 vous devez alors installer un programme GUI pour Windows. J'ai utilisé Xserver .
Une fois que vous avez installé une interface graphique, essayez les commandes suivantes:
export DISPLAY=:0
xclock
Si une horloge arrive, alors succès!
Maintenant, essayez de lancer ssh sur le serveur, puis exécutez xclock. Avez-vous toujours obtenu les messages d'erreur connect /tmp/.X11-unix/X0: Aucun fichier ou répertoire de ce type Erreur: Impossible d'ouvrir l'affichage: localhost: 10.0? C'est parce que le serveur essaie de se connecter à lui-même pour afficher l'interface graphique. Au lieu de cela, vous souhaitez que la variable DISPLAY soit définie sur une adresse où le serveur peut obtenir votre ordinateur. Donc, si c'est sur un réseau local, vous devez simplement saisir le nom de votre ordinateur. Si vous vous connectez à un serveur sur le WAN, vous devez spécifier l'IP externe de votre routeur et avoir le bon port transféré.
LAN: export DISPLAY=ComputerName:0
WAN: export DISPLAY=257.257.257.257:0
J'ai trouvé que dans WSL/Ubuntu, mon ~/.bashrc avait la ligne
$ export DISPLAY=:0
à la fin de celui-ci.
En supprimant cette ligne et en redémarrant l'application WSL/Ubuntu, j'ai constaté que la variable d'environnement DISPLAY était correctement définie sur
$ echo $DISPLAY
localhost:0
Maintenant ssh dans la machine distante en utilisant
ssh -X [email protected]
fonctionne et peut faire apparaître des fenêtres dans la machine distante.