X11転送の試行が「connect /tmp/.X11-unix/X0：No such file or directory」で失敗するのはなぜですか？

Question

私のローカルマシンでは、次のコマンドを実行します。

ssh -X me@remotemachine.com

（完全を期すために、-Yを使用して以下のすべてをテストしましたが、結果は同じです）。

予想通り、これはremotemachine.comに正常にアクセスし、すべて正常に表示されます。その後、xcalcを実行しようとすると、次のようになります。

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

だが、

$ 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が存在するだけでなく、ユニバーサルなr/w/x権限も持っています！

以前は問題なくx-forwardingを使用してきましたが、しばらくはそうではありません...

参照用のサーバー上のuname -a：

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

数時間Webを探し回っていたが成功しなかった。同じ問題についての他の言及がありますが、解決策はありません。

St&#233;phane Chazelas · Accepted Answer

Xサーバーを実行していて、DISPLAY環境変数が:0に設定されている場合、Linuxの/tmp/.X11-unix/X0で一般的に見られるUNIXドメインソケットを使用してXサーバーに接続するようにアプリケーションに指示します（ただし、以下については抽象的な名前空間最近のLinux）。

マシンにsshするとremotemachine、sshd on remotemachineはDISPLAYをlocalhost:10（たとえば）に設定します。これは、X接続がTCPマシンlocalhostのポート6010に接続します。sshdon remotemachineそこで接続をリッスンし、着信接続をsshクライアントに転送します。次に、sshクライアントは/tmp/.X11-unix/X0（ローカルXサーバーに接続するには、リモートではなく）を終了します。

Xサーバーが実行されていない（Macを使用していますか）か、UNIXドメインソケットが/tmp/.X11-unixに見つからない可能性があります。これは、sshがコンパイル時に適切に構成されていないことを意味します。時間。

UNIXソケットの適切なパスを把握するには、ローカルマシンでstrace -e connect xlogo（またはシステムの同等のパス）を試して、通常のXアプリケーションの動作を確認します。

netstat -x | grep Xも手掛かりを与えます。

記録のために、ここのLinux Debian wheezyマシンでは、Xorgはファイルシステムの/tmp/.X11-unix/X0と抽象的な名前空間（一般的に/tmp/.X11-unix/X0）の@/tmp/.X11-unix/X0の両方をリッスンします。 straceから、X11アプリケーションはデフォルトでその抽象名前空間を使用するようです。これにより、/tmp/.X11-unixが削除されてもそれらが引き続き機能するのに対し、sshはその抽象名前空間を使用しません。

m0j0 · Answer

CygwinとXmingでも同じ問題があり、リモートのLinuxサーバーに接続していました。

私の$ DISPLAY変数はCygwinでは単に "：0.0"でしたが、ローカルでは機能しましたが、リモートのsshコマンドでは機能しませんでした。

ローカルマシンで変数を「localhost：0.0」に変更すると、問題が修正されました。

export DISPLAY=localhost:0.0

私がそれをしたら、私のコマンドはうまくいきました：

ssh -Yf user@Host gvim somefile.c

init_js · Answer

これは、Linux用のWindowsサブシステム（WSL）に固有の情報で他の回答を補足するものです。受け入れられた回答は正しいです：DISPLAY変数が正しく設定されていません。しかし、正確には明確ではありませんが、なぜそれがその答えだけの場合に当てはまるのか、そのため、私はこの答えで修正しています。

Cygwin、またはLinuxのWindowsサブシステムを実行していて、X11サーバーがWindowsベース（例：VcXsrv、またはXMing）の場合、X11サーバーがリッスンしている可能性が高くなります。 a TCPポート（_127.0.0.1_ポート_6000-6010_など）は、デフォルトのUnixドメインソケット（_/tmp/.X11-unix/X0_）よりも。Unixソケットは、この時点でのWSL内のWindowsでも、Linuxのような環境のプログラムとWindowsホストで直接実行されているプログラムの間の通信は、IPソケットを介した方が一般的に簡単です。

ローカルで（つまり、ホストのCygwinまたはWSL環境から）グラフィカルアプリケーションを実行し、DISPLAY変数がデフォルト（つまり、_DISPLAY=:0.0_）に設定されている場合、アプリケーションは最初にUnixソケット_/tmp/.X11-unix/X0_を介したXサーバー。これは失敗しますが、ほとんどのアプリケーションはlocalhost上のTCP接続にフォールバックします。これは、Xサーバーがデフォルトで構成されていると想定して、サーバーへの接続に成功するはずです。

グラフィカルアプリケーションの実行からstraceログでconnect()呼び出しを探すことで、これが発生していることを確認できます。これらは通常、アプリケーションのメインウィンドウが表示される前の早い段階で発生します。

Sshがリモート側から接続をリダイレクトしている場合、このフォールバック動作は発生しないため、そのエラーが発生します。リモートのsshdは確かにX11接続をローカル側に転送しますが、sshクライアントのローカル接続は、Unixソケット経由でサーバーに到達できないため、行き止まりになります。その後、ENOENTエラーが発生します。 TCP localhostへのフォールバック接続は試行しません。

このような場合、DISPLAY変数を変更して、_:0.0_構文の代わりにTCP構文を使用することで、問題を修正できます。

_DISPLAY=127.0.0.1:0 ssh remote some-gui-application _

他の回答で述べたように、シェルプロンプトからインタラクティブにその変数をエクスポートすることもできます。

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

この行をログインシェルプロファイル初期化スクリプト（_~/.bash_profile_など）に追加して、この設定をより永続的に保存することもできます。

注：一部のシェルには、ログインセッションと非ログインセッション用に異なる初期化スクリプトがあります。たとえば、bashを使用すると、その行を非ログインスクリプト、つまり_~/.bashrc_ではなく_~/.bash_profile_に書き込むことができます。その場合は、sshによって設定された可能性のあるカスタム値を上書きしないように注意してください。最初にssh経由でホストにホッピングしてから、別のホストにホッピングした場合（つまり、X11フォワーディングをネストしている場合）がそうです。

softweyr · Answer

ディスプレイホストがmacOSである場合は、XQuartzが実行されていることを確認してください。

このエラーメッセージは、sshトンネルが機能していることを示していますが、トンネルの側のXサーバーに接続する方法を理解できません 。

古き良き時代には、Mac OS XがXQuartzの起動に使用されていましたが、macOSバージョンの端末。

smendola · Answer

私は同じ問題を抱えていました。混乱を招くのはリモートマシンでno-such-fileエラーが発生することですが、実際にはlocal（ディスプレイ）マシンではこのファイルがありません。

何が起こるかを確認するために、次のように、ディスプレイマシンで不足しているファイル（実際にはfifo）を手動で作成しました。

mkfifo /tmp/.X11-unix/X0

次に、もう一度リモートマシンにsshを実行し、見たところ、X11は正常に接続しました。

これが関連するかどうかはわかりませんが、私のディスプレイマシンはLinuxではなく、cygwinとVcXsrvを備えたWindowsです。（リモートマシンはLinuxです）

JoKalliauer · Answer

Cygwinでも同じ問題がありました。

次の* .bat-scriptを開始することで解決しました

@echo off C: chdir C:\cygwin\bin run XWin -multiwindow -clipboard -silent-dup-error run mintty.exe -i /Cygwin-Terminal.ico -

ソース： https://www.asc.tuwien.ac.at/eprog/download/win10_Anleitung.mp4

Jack Cole · Answer

LinuxのWindowsサブシステムを使用してこの問題に遭遇しました。問題は、クライアントがGUIをインストールしていないことです。これは、Windowsマシンであるため、GUIを持っているという前提のためです。

GUIがあるかどうかをテストするには、クライアントでxclockを実行します。エラーが発生した場合Error: Can't open display: :0次に、Windows用のGUIプログラムをインストールする必要があります。 Xserver を使用しました。

GUIをインストールしたら、次のコマンドを試してください。

export DISPLAY=:0 xclock

時計が出たら成功！

サーバーにsshして、xclockを実行してみます。それでもエラーメッセージが表示されましたかconnect /tmp/.X11-unix/X0：No such file or directory Error：Ca n't open display：localhost：10.0？これは、サーバーがそれ自体に接続してGUIを表示しようとしているためです。代わりに、サーバーがコンピュータを取得できるアドレスにDISPLAY変数を設定する必要があります。したがって、LAN上にある場合は、コンピュータの名前を入力するだけです。 WAN上のサーバーに接続している場合は、ルーターの外部IPを指定し、適切なポートを転送する必要があります。

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

Jeffery Martin · Answer

WSL/Ubuntuで、〜/ .bashrcに次の行があることがわかりました

$ export DISPLAY=:0

それの終わりに。

この行を削除してWSL/Ubuntuアプリを再起動すると、DISPLAY環境変数が正しく設定されていることがわかりました

$ echo $DISPLAY localhost:0

次に、sshを使用してリモートマシンにログインします。

ssh -X username@Host.ip

動作し、リモートマシンでウィンドウをポップアップできます。