Por que minha tentativa de encaminhamento do X11 falha com “connect /tmp/.X11-unix/X0: No such file or directory”?

Question

Na minha máquina local, eu corro:

ssh -X [email protected]

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

Como esperado, isso acessa o remotemachine.com, e tudo parece bem. Se eu tentar então executar o xcalc, eu obtenho:

 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

Então não só o /tmp/.X11-unix/X0 existe, ele tem permissões universais r / w / x!

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

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

Você está pesquisando na Web por algumas horas agora sem sucesso. Outras menções do mesmo problema, mas sem soluções.

    

Answer 1

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

Quando você faz o ssh para usinar remotemachine , sshd em remotemachine configura DISPLAY para localhost:10 (por exemplo), o que significa que as conexões X são feito por TCP para a porta 6010 do host local da máquina. O sshd em remotemachine escuta conexões para lá e encaminha qualquer conexão de entrada para o cliente ssh. O cliente ssh então tenta se conectar a /tmp/.X11-unix/X0 (no terminal local, não no remoto) para contatar o seu 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 esteja em /tmp/.X11-unix, o que significa que o ssh não foi configurado corretamente em tempo de compilação.

Para descobrir qual é o caminho correto para o soquete unix, você pode tentar um strace -e connect xlogo (ou o equivalente em 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 o registro, em uma máquina wheezy Linux Debian aqui, o Xorg escuta em /tmp/.X11-unix/X0 no sistema de arquivos e /tmp/.X11-unix/X0 no espaço de nomes abstrato (geralmente escrito @/tmp/.X11-unix/X0 ). De strace , os aplicativos X11 parecem agora usar esse namespace abstrato por padrão, o que explica por que eles ainda funcionam se /tmp/.X11-unix for removido, enquanto ssh não usa esse namespace abstrato.

    

Answer 2

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 ssh remoto.

A alteração da 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

    

Answer 3

Se o seu host de exibição for macOS , certifique-se de ter XQuartz em execução.

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

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

    

Answer 4

Acabei de ter o mesmo problema. O mais confuso é que você obtém o erro "no-such-file" na máquina remote , mas na verdade este arquivo está faltando na máquina local (display).

Só 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

Então ssh'ed na máquina remota novamente, e eis que X11 conectou bem.

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

    

Answer 5

Isso está complementando outras respostas com informações específicas do Windows-Subsystem para Linux. A resposta aceita está correta: sua variável DISPLAY está configurada incorretamente. Não é exatamente claro, no entanto, por que isso acontece apenas com essa resposta, então estou corrigindo com essa resposta.

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

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

Você pode confirmar que isso está acontecendo procurando connect() chamadas em registros de strace de uma execução do seu aplicativo gráfico. Esses geralmente acontecem cedo, antes que a janela principal do aplicativo apareça.

Esse comportamento de fallback não acontece quando o ssh está redirecionando uma conexão do lado remoto, então você está recebendo esse erro. O sshd está, de fato, encaminhando a conexão para o lado local, mas a conexão local do cliente ssh não tem saída quando não consegue acessar o servidor através do soquete Unix. Você está recebendo o erro ENOENT .

Nesses casos, alterar sua variável DISPLAY para usar a sintaxe TCP em vez da sintaxe :0.0 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 de seu prompt de 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 seu script de inicialização de perfil de shell de login (por exemplo, ~/.bash_profile ).

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

    

Answer 6

Eu corri para este problema usando o Windows Subsystem para Linux . O problema é que eu não tinha uma GUI instalada no cliente, por causa da suposição de que, como é uma máquina Windows, eu tenho uma GUI.

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

Quando tiver uma GUI instalada, tente os seguintes comandos:

export DISPLAY=:0
xclock

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

Agora tente ssh'ing no servidor e, em seguida, execute xclock . Você ainda recebe as mensagens de erro connect /tmp/.X11-unix/X0: Nenhum arquivo ou diretório Erro: Não é possível abrir a exibição: localhost: 10.0 ? Isso porque o servidor está tentando se conectar para exibir a GUI. Em vez disso, você deseja que a variável DISPLAY seja definida para um endereço no qual o servidor possa obter seu computador. Então, 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 roteador e encaminhar a porta adequada.

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

    

Answer 7

Se estivesse funcionando bem e parasse de funcionar sem nenhum motivo apropriado, provavelmente poderia ser uma instância X descontrolada sendo executada em segundo plano. Por favor, feche isso usando o gerenciador de tarefas.