X11 yönlendirme denemem neden “connect /tmp/.X11-unix/X0: Böyle bir dosya veya dizin yok” ile başarısız oluyor?

Yerel makinemde çalıştırıyorum:

ssh -X me@remotemachine.com

(Bütünlüğü sağlamak için, aynı sonuçları kullanarak -Y kullanarak aşağıdakilerin hepsini de test ettim).

Beklendiği gibi, bu remotemachine.com iyi erişir ve hepsi iyi görünüyor. Ancak xcalc'i çalıştırmayı denersem, şunu alıyorum:

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

Fakat,

$ 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

Yani /tmp/.X11-unix/X0 sadece var değil, evrensel r / w / x izinlerine sahip!

Daha önce hiç sorun yaşamadan x iletmeyi kullandım, ancak bir süre içinde değil ...

uname -a başvuru için sunucuda:

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

Birkaç saattir internette etrafta başarılı bir şekilde araştırma yapıyorum. Aynı sorunun diğer sözleri, ancak çözüm yok.

Çalışan bir X sunucunuz varsa ve DISPLAYortam değişkeni ayarlanmışsa :0, uygulamalara X sunucusuna genellikle Linux'ta bulunan bir unix etki alanı soketi kullanarak bağlanmasını söyler /tmp/.X11-unix/X0(yine de son Linux'ta soyut ad alanı için aşağıya bakın ) .

Makinenin uzaktan makinasına ssh yaparken , uzaktan makinenin sshdüzerinde DISPLAY'i (örneğin) ayarlar , bu kez X bağlantılarının TCP üzerinden makinenin localhost portuna TCP üzerinden yapılması anlamına gelir. remotemachine on sshd, oradaki bağlantıları dinler ve gelen bağlantıları ssh istemcisine iletir. Ssh istemcisi daha sonra X sunucunuzla bağlantı kurmak için (uzak ucunda değil, yerel uçta) bağlanmaya çalışır .localhost:10/tmp/.X11-unix/X0

Şimdi, belki de çalışan bir X sunucunuz yok (Mac’te misiniz?) Veya belki de unix alan soketi /tmp/.X11-unix’de bulunamıyor. saati.

Unix soketi için uygun yolun ne olduğunu bulmak amacıyla, strace -e connect xlogonormal bir X uygulamasının ne yaptığını görmek için yerel makinenizde bir (veya sisteminizdeki eşdeğeri) deneyebilirsiniz .

netstat -x | grep X ayrıca bir ipucu verebilir.

Kayıt için, burada Linux Debian wheezy makinesinde, Xorg hem /tmp/.X11-unix/X0dosya sisteminde hem /tmp/.X11-unix/X0de soyut ad alanında (genellikle yazılı @/tmp/.X11-unix/X0) dinler . Gönderen strace, X11 uygulamaları artık bu hala iş eğer açıklıyor varsayılan olarak o soyut ad kullanmak gibi görünüyor /tmp/.X11-unixederken, çıkarıldığında ssho soyut ad kullanmaz.

Uzak bir Linux sunucusuna bağlanarak Cygwin ve Xming ile aynı problemi yaşadım.

$ DISPLAY değişkenim, Cygwin'de basitçe ": 0.0" idi ve bu yerel olarak çalışsa da, ssh komutuyla çalışmadı.

Değişkeni "localhost: 0.0" olarak değiştirmek sorunu çözdü.

export DISPLAY=localhost:0.0

Bunu yaptıktan sonra emrim işe yaradı:

ssh -Yf user@host gvim somefile.c

Bu, diğer cevapları Linux için Windows Subsystem'in özel bilgileriyle tamamlıyor. Kabul edilen cevap doğru: DISPLAYdeğişkeniniz yanlış yapılandırılmış. Ancak tam olarak belli değil, neden bu cevabın tek başına bu durumda olduğu, bu yüzden bu cevabı düzeltiyorum.

Linux için cygwin veya Windows-Subsystem kullanıyorsanız ve X11 sunucunuz windows tabanlıysa (örn VcXsrv. Veya XMing), X11 sunucunuzun bir TCP portunda ( 127.0.0.1TCP portlarında olduğu gibi) dinlemesi daha muhtemeldir 6000-6010. varsayılan Unix alan soketi ( /tmp/.X11-unix/X0). Unix soketleri, Windows'ta bu noktada WSL dahilinde bile iyi bir şekilde desteklenmemektedir. Linux benzeri ortamdaki programlar ile doğrudan Windows ana bilgisayarında çalışan programlar arasında iletişim kurmak, genellikle IP soketleri üzerinden daha kolaydır.

Grafik uygulamaları yerel olarak çalıştırdığınızda (örneğin, ana makinenizin Cygwin veya WSL ortamından) ve DISPLAYdeğişkeniniz varsayılana (yani DISPLAY=:0.0) ayarlandığında , uygulamalar ilk önce Unix soketi üzerinden X sunucusuna bağlanmaya çalışır /tmp/.X11-unix/X0. Bu başarısız olur, ancak çoğu uygulama, localhostX sunucunuzun varsayılan ayarlarla yapılandırıldığı varsayılarak, sunucuya ulaşmada başarılı olması gereken bir TCP bağlantısına geri döner.

Bunun connect()bir grafiksel uygulamanızın strace loglarındaki çağrıları arayarak bunun olduğunu doğrulayabilirsiniz . Bunlar genellikle uygulamanın ana penceresi görünmeden önce daha erken olur.

Bu geri dönüş davranışı ssh uzak taraftan bir bağlantıyı yönlendirirken olmaz, bu yüzden bu hatayı alıyorsunuz. sshdgerçekten bağlantıyı yerel tarafa iletiyor, ancak ssh istemcisinin yerel bağlantısı, sunucuya Unix soketi üzerinden ulaşamadığı için sona eriyor. Daha sonra ENOENThatayı alıyorsunuz .

Bu gibi durumlarda, DISPLAYdeğişkeni sözdizimi yerine TCP sözdizimini kullanmak üzere değiştirmek :0.0sorunu çözebilir:

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

Bahsedilen diğer cevaplar gibi, bu değişkeni kabuk isteminizden etkileşimli olarak da aktarabilirsiniz:

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

Bu ayarı ayrıca oturum açma kabuğu profil başlatma komut dosyasına o satırı ekleyerek de daha kalıcı olarak saklayabilirsiniz ~/.bash_profile.

Not: Bazı kabuklarda, oturum açma ve oturum açmayan oturumlar için farklı bir başlatma komut dosyası bulunur. Örneğin, bash ile bu satırı giriş yapılmayan komut dosyasına (örneğin ~/.bashrcyerine) yazabilirsiniz ~/.bash_profile. Bunu yaparsanız, ssh tarafından ayarlanmış olabilecek herhangi bir özel değeri geçersiz kılmamaya dikkat edin. Bu, ilk önce ssh ile ana bilgisayarınıza atlayıp ardından başka bir ana bilgisayara atlayıp (X11'inizi yönlendirme içine yerleştirirseniz) durum böyle olacaktır.

Ekran sunucunuz macOS ise , XQuartz uygulamasının çalıştığından emin olun .

Bu hata mesajı, ssh tünelinin çalıştığını söylüyor, ancak tünelin tarafındaki X sunucusuna nasıl bağlanacağını çözemiyor .

Eski güzel günlerde Mac OS X , XQuartz'ı sizin için başlatırdı, ancak terminalin macOS sürümünde bu hoş küçük özelliği açıkça bıraktık .

Ben de aynı sorunu yaşadım. Şaşırtıcı olan şey, uzaktaki makinede böyle bir dosya hatası olmamasıdır , ancak gerçekte bu dosya yerel (ekran) makinesinde yoktur.

Sadece ne olacağını görmek için ekran makinesinde eksik dosyayı manuel olarak (fifo, aslında) oluşturdum, şöyle:

mkfifo /tmp/.X11-unix/X0

Sonra tekrar uzaktaki makineye ssh'ed oldu ve bak, X11 iyi bağlanmış.

Bunun alakalı olup olmadığını bilmiyorum, ancak ekran makinem Linux değil, cygwin ve VcXsrv içeren Windows. (Uzak makine Linux'tur)

Linux için Windows Alt Sistemini kullanarak bu problemle karşılaştım . Sorun şu ki, istemcide bir GUI yüklü değildi, çünkü bir Windows makinesi olduğundan, bir GUI'ye sahip olduğumu varsayıyordum.

Bir GUI'niz olup olmadığını test etmek xclockiçin istemcide yürütün . Hatayı Error: Can't open display: :0alırsanız, Windows için bir GUI programı yüklemeniz gerekir. Xserver kullandım .

Bir GUI kurduktan sonra aşağıdaki komutları deneyin:

export DISPLAY=:0
xclock

Bir saat gelirse, o zaman başarı!

Şimdi sunucuya ssh'lemeyi dene, sonra çalışıyor xclock. Hala /tmp/.X11-unix/X0 adresindeki connect hata mesajlarını aldınız mı? Böyle bir dosya veya dizin yok Hata: Ekran açılamıyor: localhost: 10.0 ? Bunun nedeni, sunucunun GUI'yi görüntülemek için kendisine bağlanmaya çalıştığıdır. Bunun yerine, DISPLAY değişkeninin sunucunun bilgisayarınızı alabileceği bir adrese ayarlanmasını istiyorsunuz. Yani bir LAN üzerindeyse, sadece bilgisayarınızın adını girersiniz. WAN üzerindeki bir sunucuya bağlanıyorsanız, yönlendiricinizin harici IP'sini belirtmeniz ve doğru bağlantı noktasını iletmeniz gerekir.

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

İyi çalışıyor ve herhangi bir uygun sebep olmadan çalışmayı durduruyorsa, muhtemelen arka planda çalışan kontrolsüz bir X örneği olabilir. Lütfen görev yöneticisini kullanarak bunu kapatın.