Ciò integra altre risposte con informazioni specifiche dal sottosistema Windows per Linux. La risposta accettata è corretta: la tua DISPLAYvariabile non è configurata correttamente. Non è esattamente chiaro, tuttavia, perché sia il caso di quella sola risposta, quindi sto rimediando a questa risposta.
Se si esegue cygwin o il sottosistema Windows per Linux e il server X11 è basato su Windows (ad es VcXsrv , o XMing), è più probabile che il tuo server X11 sia in ascolto su una porta TCP (come 127.0.0.1su porte TCP 6000-6010) che su il socket del dominio Unix predefinito ( /tmp/.X11-unix/X0). I socket Unix non sono ben supportati su Windows in questo momento, anche all'interno di WSL. Anche la comunicazione tra programmi in ambiente simile a Linux e programmi in esecuzione direttamente sull'host Windows è generalmente più semplice su socket IP.
Quando si eseguono applicazioni grafiche localmente (ovvero dall'ambiente Cygwin o WSL del proprio host) e il proprio DISPLAY variabile è impostata sul valore predefinito (ad es. DISPLAY=:0.0), Le applicazioni tenteranno innanzitutto di connettersi al server X tramite il socket Unix /tmp/.X11-unix/X0. Ciò fallirà, ma la maggior parte delle applicazioni eseguirà quindi il fallback su una connessione TCP localhost, che dovrebbe riuscire a raggiungere il server, presupponendo che il server X sia configurato con impostazioni predefinite.
È possibile confermare che ciò sta accadendo cercando le connect()chiamate nei registri di strace da un'esecuzione dell'applicazione grafica. Generalmente ciò accadrebbe presto, prima che appaia la finestra principale dell'applicazione.
Questo comportamento di fallback non si verifica quando ssh sta reindirizzando una connessione dal lato remoto, quindi stai ottenendo quell'errore. sshdsta effettivamente inoltrando la connessione al lato locale, ma la connessione locale del client ssh si interrompe poiché non riesce a raggiungere il server tramite il socket Unix. Viene quindi visualizzato l' ENOENTerrore.
In questi casi, modificando la DISPLAYvariabile per utilizzare la sintassi TCP anziché la :0.0sintassi, è possibile risolvere il problema:
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
Come altre risposte menzionate, è anche possibile esportare quella variabile in modo interattivo dal prompt della shell:
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
È inoltre possibile memorizzare questa impostazione in modo permanente aggiungendo quella riga allo script di inizializzazione del profilo della shell di accesso (ad es ~/.bash_profile .).
Nota: alcune shell hanno uno script di inizializzazione diverso per le sessioni di accesso e non di accesso. Ad esempio, con bash è possibile scrivere quella riga nello script non di accesso, ovvero ~/.bashrcanziché ~/.bash_profile. Se lo fai, fai attenzione a non sovrascrivere alcun valore personalizzato che potrebbe essere stato impostato da ssh. Questo sarebbe il caso se saltassi prima nel tuo host tramite ssh e poi saltassi di nuovo in un altro host (annidando così il tuo inoltro X11).
strace -fo /tmp/trace ssh....per verificare che provi a connettere quel socket di dominio Unix.