X11転送の試みが「connect /tmp/.X11-unix/X0:そのファイルまたはディレクトリなし」というメッセージで失敗するのはなぜですか?

X11転送の試みが「connect /tmp/.X11-unix/X0:そのファイルまたはディレクトリなし」というメッセージで失敗するのはなぜですか?

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

ssh -X [email protected]

(完全性のために、-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

数時間オンラインで検索しましたが、成功しませんでした。他の人も同じ問題に言及しましたが、解決策はありませんでした。

答え1

CygwinとXmingを使用してリモートLinuxサーバーに接続するときに同じ問題が発生しました。

私の$ DISPLAY変数はCygwinでは ":0.0"で、ローカルでは機能しますが、リモートSSHコマンドでは機能しません。

ローカルコンピュータで変数を「localhost:0.0」に変更することで問題を解決しました。

export DISPLAY=localhost:0.0

これを行うと、私のコマンドはうまくいきました。

ssh -Yf user@host gvim somefile.c

答え2

Xサーバーが稼働していてDISPLAY環境変数がに設定されている場合、:0これは通常Linux上で見つかったUnixドメインソケットを使用してXサーバーに接続するようにアプリケーションに指示します/tmp/.X11-unix/X0(下記参照)。抽象名前空間最近のLinuxでは)。

SSHでマシンに接続するときリモートマシンsshd存在するリモートマシンたとえば、DISPLAYを設定すると、localhost:10X接続は実際にはTCPを介してコンピュータのローカルホストのポート6010に行われます。 SSHDを開くリモートマシンそこから接続を受信し、着信接続をSSHクライアントに転送します。その後、SSHクライアントは/tmp/.X11-unix/X0Xサーバーに接続するために(リモートではなくローカル側で)接続を試みます。

現在実行中のXサーバーがないか(Macを使用していますか)、/tmp/.X11-unixで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

答え3

これは、Linux用のWindowsサブシステム(WSL)の特定の情報を含む他の回答に追加されます。これ受け入れられた回答正しい:DISPLAY変数が正しく構成されていません。しかし、この回答だけではなぜこのようなことが起こるのか明確ではないので、この回答を使って問題を解決しています。

cygwinまたはLinux用のWindowsサブシステムを実行していて、X11サーバーがWindowsベース(たとえば、またはVcXsrv)の場合、X11サーバーはデフォルトポートではなくXMingTCPポート(Unix127.0.0.1ポートなど)でリッスンする可能性が高くなります。6000-6010ポート Unix DomainSocket( /tmp/.X11-unix/X0)。現在、UnixソケットはWSLでもWindowsでうまくサポートされていません。また、通常、Linux と同様の環境のプログラムと IP ソケットを介して Windows ホスト上で直接実行されるプログラムとの間の通信が容易になります。

グラフィカルアプリケーションをローカルで(つまり、ホストのCygwinまたはWSL環境で)実行し、DISPLAY変数がデフォルト(つまりDISPLAY=:0.0)に設定されている場合、アプリケーションは最初にUnixを介してXサーバーに接続しようとします。ソケット/tmp/.X11-unix/X0。これは失敗しますが、ほとんどのアプリケーションはlocalhostXサーバーがデフォルトで構成されていると仮定し、サーバーに正常に接続されたTCP接続に置き換えられます。

connect()実行中のグラフィックアプリケーションのトレースログで呼び出しを見つけて、この問題が発生しているかどうかを確認できます。これは通常、アプリケーションのメインウィンドウが表示される前に発生します。

キーポイント:SSHがリモート側で接続をリダイレクトすると、この代替動作は発生しないため、エラーが発生します。sshdリモートにあるのはX11接続をローカル側に転送しますが、SSHクライアントのローカル接続はUnixソケットを介してサーバーに接続できないため終了します。これによりENOENTエラーが発生します。 TCPローカルホストへの代替接続を試みません。

修理する:この場合、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転送がネストされます)。

答え4

ちょうど同じ問題が発生しました。混乱しても、no-such-file エラーが発生します。離れてコンピュータにありますが、ファイルは実際にオンになっています。地元の(ディスプレイ)マシン。

何が起こるかを確認するために、次のように表示システムに欠落しているファイル(実際にはfifo)を手動で作成しました。

mkfifo /tmp/.X11-unix/X0

次に、リモートコンピュータにSSHを介して再度アクセスしてみてください。 X11接続が正常に動作します。

これが関連しているかどうかはわかりませんが、私のディスプレイシステムはLinuxではなく、cygwinとVcXsrvを持つWindowsです。 (リモートコンピュータはLinuxです)

関連情報