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


33

ローカルマシンで、次を実行します。

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フォワーディングを問題なく使用しましたが、しばらくの間ではありません...

参照用にサーバー上のuname -a:

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

成功せずに数時間ウェブ上を検索していました。同じ問題に関する他の言及はありますが、解決策はありません。


ここで確認する必要があるのは、リモートマシンではなくローカルマシン上のファイルです。strace -fo /tmp/trace ssh....Unixドメインソケットに接続しようとするかどうかを確認するために使用します。
ステファンシャゼル

あ!それかもしれません。奇妙なことに、私のローカルマシンには/tmp/.X11-unix/ディレクトリがありません。
ジョンDoucette

回答:


24

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

sshでマシンremotemachineに接続するとsshdremotemachineでDISPLAYがlocalhost:10(たとえば)設定されます。これは、X接続がTCP経由でマシンlocalhostのポート6010に行われることを意味します。remotemachineの sshdは、そこの接続をリッスンし、着信接続を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喘鳴のマシンに、Xorgが、両方をリッスンし/tmp/.X11-unix/X0、ファイルシステム内および/tmp/.X11-unix/X0上の抽象名前空間(一般的に書かれました@/tmp/.X11-unix/X0)。straceX11アプリケーションは現在、これらの静止仕事ならば理由を説明し、デフォルトではその抽象名前空間、使用するように見える/tmp/.X11-unix一方で、除去するsshこと、抽象名前空間を使用していません。


1
またはlsof -p <PID of your local X server>/some/thing/Xnファイルを見つけることができる場所(n自分のDISPLAY番号)を確認します。
ペテルフ

おかげで、これは非常に役に立ちました。どういうわけか、/ tmp / .X11-unix / X0ファイルは削除されましたが、まだXサーバーが実行されていました。クイックリブートで問題が解決したようです。おそらく私がしばらく前に行ったいくつかの更新が原因です。
ジョンドゥーチェ

6
DISPLAY変数を ":0.0"から "localhost:0.0"に変更することで、少なくともCygwinからLinuxに接続できるようになりました。
m0j0

FWIW、ローカルWindowsをリモートUNIXに接続しているため、ホストからstartxwin(後にapt-cyg install xinit)実行する必要がありましたcygwin
ジョナサン

40

CygwinとXmingで同じ問題が発生し、リモートLinuxサーバーに接続しました。

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

変数を「localhost:0.0」に変更すると、問題が修正されました。

export DISPLAY=localhost:0.0

それをしたら、私のコマンドは機能しました:

ssh -Yf user@host gvim somefile.c

5
これは、Windows Services for Linuxを使用している場合でも問題でした。
-lapo

1
どのサーバーでexport ...コマンドを実行しましたか?1)ローカルマシン2)サーバー
abalter

1
@abalterローカルマシンで実行してくれました
-tralston

3
設定しDISPLAY=:0 ssh -Y $hostたので、Cygwin ssh + VcXsrvで2時間のデバッグ問題を費やしました。DISPLAY=localhost:0魔法のように解決された問題に変更します。
18年

1
Windowsでubuntuサブシステムを実行するのにまだ役立つ便利な答え
Tom Swifty

6

これは、Windows-Subsystem for Linux固有の情報で他の回答を補完しています。受け入れ答えは正しいです:あなたのDISPLAY変数が正しく設定されていません。ただし、その答えだけでそれが当てはまる理由は明確ではないため、この答えで修正しています。

あなたがLinux用のCygwin、またはWindowsサブシステムを実行している、とあなたのX11サーバーがWindowsベースの(例えばある場合VcXsrv、またはXMing)、それは可能性が高いあなたのX11サーバがTCPポートでリッスンしていること(例えばある127.0.0.1TCPポート上6000-6010)よりもデフォルトのUnixドメインソケット(/tmp/.X11-unix/X0)。Unixソケットは、WSL内であっても、現時点ではWindowsで十分にサポートされていません。Linuxライクな環境のプログラムとWindowsホストで直接実行されているプログラム間の通信も、一般にIPソケットよりも簡単です。

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

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

sshがリモート側から接続をリダイレクトしている場合、そのフォールバック動作は発生しないため、そのエラーが発生します。sshd実際に接続をローカル側に転送していますが、sshクライアントのローカル接続は、Unixソケットを介してサーバーに到達できないために行き詰まります。その後、ENOENTエラーが発生します。

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

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フォワーディングをネストする場合)に該当します。


3

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

このエラーメッセージは、sshトンネルが機能していることを示していますが、トンネルの横にあるXサーバーに接続する方法がわかりません。

古き良き時代、Mac OS XはXQuartzを起動していたが、macOSバージョンの端末ではこの素敵な機能を放棄したようだ。


フォローアップ:Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0「XQuartzを起動した後、終了してSSHで戻る必要があります」FWIW ...
rogerdpack

1

私はちょうど同じ問題を抱えていました。紛らわしいのは、リモートマシンでno-such-fileエラーが発生することですが、実際にはローカル(ディスプレイ)マシンではこのファイルが欠落しています。

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

mkfifo /tmp/.X11-unix/X0

その後、再びリモートマシンにsshし、見よ、X11が正常に接続されました。

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


4
/tmp/.X11-unix/X0FIFOではなくUNIXドメインソケットです
-Samveen

0

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

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

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

export DISPLAY=:0
xclock

時計が出たら成功!

次に、サーバーにsshしてからを実行してくださいxclock。それでもエラーメッセージが表示されました/tmp/.X11-unix/X0に接続します:そのようなファイルまたはディレクトリはありませんエラー:ディスプレイを開くことができません:localhost:10.0?これは、サーバーがそれ自体に接続してGUIを表示しようとしているためです。代わりに、サーバーがコンピューターを取得できるアドレスにDISPLAY変数を設定する必要があります。したがって、LAN上にある場合は、コンピューターの名前を入力するだけです。WAN上のサーバーに接続する場合、ルーターの外部IPを指定し、適切なポートを転送する必要があります。

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


「Xフォワーディング」とは、「リモートマシン(サーバーの場合)で実行されているアプリケーションからローカルマシン(クライアントの場合)にXプロトコルをトンネルする」ことを意味するため、もちろんXサーバーを実行する必要があります「任意のGUIプログラム」)ローカルマシン上。「GUIがあります」にもかかわらず、Windows自体はXプロトコルを理解しません。
dirkt

-2

適切に動作せず、適切な理由もなく動作を停止した場合、おそらく制御されていないXインスタンスがバックグラウンドで実行されている可能性があります。タスクマネージャを使用して閉じてください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.