Por que minha tentativa de encaminhamento do X11 falha com "connect /tmp/.X11-unix/X0: Esse arquivo ou diretório não existe"?

Na minha máquina local, eu corro:

ssh -X me@remotemachine.com

(Para completar, também testei todos os seguintes usando -Y com resultados idênticos).

Como esperado, isso acessa remotemachine.com e tudo parece bem. No entanto, se eu tentar executar o xcalc, recebo:

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

Mas,

$ 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

Portanto, não apenas existe /tmp/.X11-unix/X0, mas possui permissões universais de r / w / x!

Eu já usei o encaminhamento x sem problemas, embora não em algum tempo ...

uname -a no servidor para referência:

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

Faz uma pesquisa na web há algumas horas, agora sem sucesso. Outras menções do mesmo problema, mas sem soluções.

Se você tiver um servidor X em execução e a DISPLAYvariável de ambiente estiver configurada como :0, isso informa aos aplicativos para se conectarem ao servidor X usando um soquete de domínio unix que geralmente pode ser encontrado no Linux /tmp/.X11-unix/X0(embora veja abaixo o espaço para nome abstrato no Linux recente) .

Quando você faz o ssh na máquina remotemachine , sshdna remotemachine define DISPLAY como localhost:10(por exemplo), o que significa que, dessa vez, as conexões X serão feitas pelo TCP na porta 6010 do host local da máquina. O sshd no remotemachine escuta as conexões lá e encaminha qualquer conexão de entrada para o cliente ssh. O cliente ssh tenta se conectar /tmp/.X11-unix/X0(no local, não no remoto) para entrar em contato com o servidor X.

Agora, talvez você não tenha um servidor X em execução (você está no Mac?) Ou talvez o soquete do domínio unix não seja encontrado em /tmp/.X11-unix, o que significa que o ssh não foi configurado corretamente na compilação Tempo.

Para descobrir qual é o caminho adequado para o soquete unix, você pode tentar um strace -e connect xlogo(ou o equivalente no seu sistema) em sua máquina local para ver o que um aplicativo X normal faz.

netstat -x | grep X também pode dar uma pista.

Para constar, em uma máquina wheezy Linux Debian aqui, o Xorg escuta no /tmp/.X11-unix/X0sistema de arquivos e /tmp/.X11-unix/X0no espaço de nome abstrato (geralmente escrito @/tmp/.X11-unix/X0). A partir de agora strace, os aplicativos X11 parecem usar esse espaço para nome abstrato por padrão, o que explica por que eles ainda funcionam se /tmp/.X11-unixforem removidos, enquanto sshnão usam esse espaço para nome abstrato.

Eu tive o mesmo problema com o Cygwin e o Xming, conectando-me a um servidor Linux remoto.

Minha variável $ DISPLAY era simplesmente ": 0.0" no Cygwin e, embora isso funcione localmente, não funcionou com o comando remote ssh.

Alterar a variável para "localhost: 0.0" corrigiu o problema.

export DISPLAY=localhost:0.0

Depois que fiz isso, meu comando funcionou:

ssh -Yf user@host gvim somefile.c

Isso complementa outras respostas com informações específicas do Windows-Subsystem for Linux. A resposta aceita está correta: sua DISPLAYvariável está configurada incorretamente. Não está exatamente claro, no entanto, por que esse é o caso apenas dessa resposta, então estou corrigindo com essa resposta.

Se você estiver executando o cygwin, ou Windows-Subsystem for Linux, e o servidor X11 for baseado em janelas (por exemplo VcXsrv, ou XMing), é mais provável que o servidor X11 esteja escutando uma porta TCP (como 127.0.0.1nas portas TCP 6000-6010) do que em o soquete de domínio Unix padrão ( /tmp/.X11-unix/X0). Soquetes Unix não são bem suportados no Windows neste momento, mesmo dentro da WSL. A comunicação entre programas no ambiente Linux e programas executados diretamente no host do Windows também é geralmente mais fácil através de soquetes IP.

Quando você executa aplicativos gráficos localmente (por exemplo, do ambiente Cygwin ou WSL do seu host) e sua DISPLAYvariável é definida como padrão (por exemplo DISPLAY=:0.0), os aplicativos primeiro tentam se conectar ao servidor X através do soquete Unix /tmp/.X11-unix/X0. Isso falhará, mas a maioria dos aplicativos fará o fallback para uma conexão TCP ativada localhost, que deverá alcançar o servidor, supondo que o servidor X esteja configurado com padrões.

Você pode confirmar que isso está acontecendo procurando connect()chamadas nos logs de rastreamento de uma execução do seu aplicativo gráfico. Geralmente, esses eventos acontecem desde o início, antes da janela principal do aplicativo aparecer.

Esse comportamento de fallback não ocorre quando o ssh está redirecionando uma conexão do lado remoto, então você está recebendo esse erro. sshdestá de fato encaminhando a conexão para o lado local, mas a conexão local do cliente ssh acaba porque ele não alcança o servidor pelo soquete Unix. Você está recebendo o ENOENTerro.

Nesses casos, alterar sua DISPLAYvariável para usar a sintaxe TCP em vez da :0.0sintaxe, pode corrigir o problema:

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

Como outras respostas mencionadas, você também pode exportar essa variável interativamente do prompt do shell:

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

Você também pode armazenar essa configuração de forma mais permanente, adicionando essa linha ao script de inicialização do perfil do shell de login (por exemplo ~/.bash_profile).

Nota: Alguns shells têm um script de inicialização diferente para sessões de logon e não logon. Por exemplo, com o bash, você pode escrever essa linha no script de não login, ou seja ~/.bashrc, em vez de ~/.bash_profile. Se o fizer, tome cuidado para não substituir qualquer valor personalizado que possa ter sido definido pelo ssh. Esse seria o caso se você estivesse pulando primeiro em seu host via ssh e depois pulando novamente em outro host (aninhando assim seu encaminhamento X11).

Se o seu host de exibição for o macOS , verifique se o XQuartz está em execução.

Esta mensagem de erro informa que o túnel ssh está funcionando, mas não consegue descobrir como se conectar ao servidor X do seu lado do túnel .

Antigamente, o Mac OS X costumava iniciar o XQuartz para você, mas aparentemente abandonamos esse pequeno recurso na versão macOS do terminal.

Eu apenas tive o mesmo problema. O mais confuso é que você obtém o erro sem esse arquivo na máquina remota , mas na verdade esse arquivo está ausente na máquina local (de exibição).

Apenas para ver o que aconteceria, criei manualmente o arquivo ausente (fifo, na verdade), na máquina de exibição, assim:

mkfifo /tmp/.X11-unix/X0

Depois ssh'ed na máquina remota novamente, e eis que X11 conectado bem.

Não sei se isso é relevante ou não, mas minha máquina de vídeo não é Linux, é Windows com cygwin e VcXsrv. (A máquina remota é Linux)

Corri para esse problema usando o Windows Subsystem for Linux . O problema é que eu não tinha uma GUI instalada no cliente, devido à suposição de que, como é uma máquina Windows, eu tenho uma GUI.

Para testar se você possui uma GUI, execute xclockno cliente. Se você receber o erro Error: Can't open display: :0, precisará instalar um programa GUI para Windows. Eu usei o Xserver .

Depois de instalar uma GUI, tente os seguintes comandos:

export DISPLAY=:0
xclock

Se um relógio chegar, então sucesso!

Agora tente ssh'ing no servidor e execute xclock. Você ainda recebeu as mensagens de erro connect /tmp/.X11-unix/X0: Não existe esse arquivo ou diretório Erro: Não é possível abrir a tela: localhost: 10.0 ? Isso ocorre porque o servidor está tentando se conectar para exibir a GUI. Em vez disso, você deseja que a variável DISPLAY seja definida como um endereço no qual o servidor possa obter o seu computador. Portanto, se estiver em uma LAN, basta colocar o nome do seu computador. Se você estiver se conectando a um servidor na WAN, precisará especificar o IP externo do seu roteador e ter a porta adequada encaminhada.

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

Se estivesse funcionando bem e parasse de funcionar sem motivo adequado, provavelmente poderia ser uma instância X não controlada em execução em segundo plano. Por favor, feche isso usando o gerenciador de tarefas.