Tại sao nỗ lực chuyển tiếp X11 của tôi không thành công với các kết nối /tmp/.X11-unix/X0: Không có tệp hoặc thư mục như vậy?

Trên máy cục bộ của tôi, tôi chạy:

ssh -X me@remotemachine.com

(Để hoàn thiện, tôi cũng đã kiểm tra tất cả các cách sau bằng cách sử dụng -Y với kết quả giống hệt nhau).

Như mong đợi, điều này truy cập vào remotemachine.com tốt, và tất cả đều xuất hiện tốt. Nếu sau đó tôi cố chạy xcalc, tôi nhận được:

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

Nhưng,

$ 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

Vì vậy, không chỉ tồn tại /tmp/.X11-unix/X0, nó còn có quyền r / w / x phổ quát!

Trước đây tôi đã sử dụng chuyển tiếp x mà không gặp sự cố, mặc dù không phải trong một thời gian ...

uname -a trên máy chủ để tham khảo:

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

Tìm kiếm trên web trong một vài giờ mà không thành công. Đề cập khác của cùng một vấn đề, nhưng không có giải pháp.

Nếu bạn có máy chủ X đang chạy và DISPLAYbiến môi trường được đặt thành :0, nó sẽ báo cho các ứng dụng kết nối với máy chủ X bằng cách sử dụng ổ cắm miền unix thường được tìm thấy trên Linux /tmp/.X11-unix/X0(mặc dù hãy xem bên dưới về không gian tên trừu tượng trên Linux gần đây) .

Khi bạn ssh vào máy remotemachine , sshdtrên remotemachine sẽ đặt HIỂN THỊ localhost:10(ví dụ), điều này có nghĩa là các kết nối X sẽ được thực hiện qua TCP tới cổng 6010 của máy localhost. sshd trên remotemachine lắng nghe các kết nối trên đó và chuyển tiếp mọi kết nối đến máy khách ssh. Máy khách ssh sau đó cố gắng kết nối với/tmp/.X11-unix/X0 (ở đầu cục bộ, không phải từ xa) để liên hệ với máy chủ X của bạn.

Bây giờ, có thể bạn không có máy chủ X đang chạy (bạn có trên Mac không?) Hoặc có thể không tìm thấy ổ cắm tên miền unix trong /tmp/.X11-unix, điều đó có nghĩa là ssh chưa được cấu hình đúng lúc biên dịch thời gian.

Để tìm ra đường dẫn thích hợp cho ổ cắm unix, bạn có thể thử một strace -e connect xlogo(hoặc tương đương trên hệ thống của bạn) trên máy cục bộ của bạn để xem ứng dụng X bình thường làm gì.

netstat -x | grep X cũng có thể đưa ra một đầu mối.

Đối với bản ghi, trên máy Linux Linux khò khè ở đây, Xorg lắng nghe cả /tmp/.X11-unix/X0trong hệ thống tệp và /tmp/.X11-unix/X0trên không gian tên trừu tượng (thường được viết @/tmp/.X11-unix/X0). Từ strace, các ứng dụng X11 dường như sử dụng không gian tên trừu tượng đó theo mặc định, điều này giải thích tại sao chúng vẫn hoạt động nếu /tmp/.X11-unixbị xóa, trong khi sshkhông sử dụng không gian tên trừu tượng đó.

Tôi gặp vấn đề tương tự với Cygwin và Xming, kết nối với máy chủ Linux từ xa.

Biến $ HIỂN THỊ của tôi chỉ đơn giản là ": 0,0" trong Cygwin và mặc dù nó hoạt động cục bộ, nhưng nó không hoạt động với lệnh ssh từ xa.

Thay đổi biến thành "localhost: 0.0" đã khắc phục sự cố.

export DISPLAY=localhost:0.0

Khi tôi đã làm điều đó, lệnh của tôi đã làm việc:

ssh -Yf user@host gvim somefile.c

Điều này bổ sung cho các câu trả lời khác với thông tin cụ thể từ Windows - Hệ thống con cho Linux. Các câu trả lời được chấp nhận là đúng: bạn DISPLAYbiến được cấu hình không đúng. Tuy nhiên, điều đó không rõ ràng chính xác tại sao chỉ có trường hợp từ câu trả lời đó, vì vậy tôi đang hồi tưởng với câu trả lời này.

Nếu bạn đang chạy cygwin hoặc Windows-subsystem cho Linux và máy chủ X11 của bạn dựa trên windows (ví dụ: VcXsrvhoặc XMing), nhiều khả năng máy chủ X11 của bạn đang lắng nghe trên cổng TCP (chẳng hạn như 127.0.0.1trên các cổng TCP6000-6010 ) ổ cắm tên miền Unix mặc định (/tmp/.X11-unix/X0 ). Ổ cắm Unix không được hỗ trợ tốt trên Windows tại thời điểm này, ngay cả trong WSL. Giao tiếp giữa các chương trình trong môi trường giống như Linux và các chương trình chạy trực tiếp trên máy chủ windows cũng thường dễ dàng hơn các ổ cắm IP.

Khi bạn chạy các ứng dụng đồ họa cục bộ (tức là từ môi trường Cygwin hoặc WSL của máy chủ của bạn) và của bạn DISPLAY biến được đặt thành mặc định (nghĩa là DISPLAY=:0.0), trước tiên các ứng dụng sẽ cố gắng kết nối với máy chủ X thông qua ổ cắm Unix /tmp/.X11-unix/X0. Điều này sẽ thất bại, nhưng hầu hết các ứng dụng sẽ chuyển sang kết nối TCP trênlocalhost , điều này sẽ thành công trong việc tiếp cận máy chủ, giả sử máy chủ X của bạn được cấu hình với mặc định.

Bạn có thể xác nhận rằng điều này đang xảy ra bằng cách tìm kiếm connect() cuộc gọi trong nhật ký strace từ một ứng dụng đồ họa của bạn. Những điều đó thường sẽ xảy ra sớm, trước khi cửa sổ chính của ứng dụng xuất hiện.

Hành vi dự phòng đó không xảy ra khi ssh đang chuyển hướng kết nối từ phía xa, do đó bạn đang gặp phải lỗi đó. sshdthực sự đang chuyển tiếp kết nối đến phía cục bộ, nhưng kết nối cục bộ của máy khách ssh đã hết hạn khi không thể truy cập máy chủ qua ổ cắm Unix. Bạn đang nhận được ENOENTlỗi.

Trong các trường hợp như vậy, thay đổi DISPLAYbiến của bạn để sử dụng cú pháp TCP thay vì:0.0 cú pháp, có thể khắc phục sự cố:

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

Giống như các câu trả lời khác được đề cập, bạn cũng có thể xuất biến đó một cách tương tác từ dấu nhắc shell của bạn:

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

Bạn cũng có thể lưu trữ cài đặt này lâu dài hơn bằng cách thêm dòng đó vào tập lệnh khởi tạo hồ sơ shell đăng nhập của bạn (ví dụ ~/.bash_profile).

Lưu ý: Một số shell có tập lệnh khởi tạo khác nhau cho các phiên đăng nhập và không đăng nhập. Chẳng hạn, với bash, bạn có thể viết dòng đó vào tập lệnh không đăng nhập, tức là ~/.bashrcthay vì ~/.bash_profile. Nếu bạn làm như vậy, hãy cẩn thận không ghi đè bất kỳ giá trị tùy chỉnh nào có thể được đặt bởi ssh. Đó sẽ là trường hợp nếu bạn lần đầu tiên nhảy vào máy chủ của mình thông qua ssh và sau đó nhảy lại vào một máy chủ khác (do đó lồng vào chuyển tiếp X11 của bạn).

Nếu máy chủ hiển thị của bạn là macOS , hãy đảm bảo bạn có XQuartz đang chạy.

Thông báo lỗi này cho bạn biết đường hầm ssh đang hoạt động, nhưng nó không thể tìm ra cách kết nối với máy chủ X ở bên cạnh đường hầm của bạn .

Ngày xưa, Mac OS X đã từng khởi động XQuartz cho bạn, nhưng rõ ràng chúng tôi đã từ bỏ tính năng nhỏ xinh này trong phiên bản macOS của thiết bị đầu cuối.

tôi chỉ có cùng một vấn đề. Điều khó hiểu là bạn gặp phải lỗi không có tệp như vậy trên máy từ xa , nhưng thực sự tệp này bị thiếu trên máy cục bộ (hiển thị).

Chỉ để xem điều gì sẽ xảy ra, tôi đã tự tạo tập tin bị thiếu (fifo, thực tế), trên máy hiển thị, như thế này:

mkfifo /tmp/.X11-unix/X0

Sau đó ssh'ed vào máy từ xa một lần nữa, và lo và kìa, X11 kết nối tốt.

Tôi không biết điều này có liên quan hay không, nhưng máy hiển thị của tôi không phải là Linux, đó là Windows với cygwin và VcXsrv. (Máy từ xa là Linux)

Tôi gặp vấn đề này khi sử dụng Hệ thống con Windows cho Linux . Vấn đề là tôi không cài đặt GUI trên máy khách, vì giả định rằng vì là máy Windows nên tôi có GUI.

Để kiểm tra xem bạn có GUI hay không, hãy thực hiện xclocktrên máy khách. Nếu bạn gặp lỗi Error: Can't open display: :0thì bạn cần cài đặt chương trình GUI cho Windows. Tôi đã sử dụng Xserver .

Khi bạn đã cài đặt GUI, hãy thử các lệnh sau:

export DISPLAY=:0
xclock

Nếu một chiếc đồng hồ xuất hiện, thì thành công!

Bây giờ hãy thử ssh'ing vào máy chủ, sau đó chạy xclock. Bạn vẫn nhận được thông báo lỗi kết nối /tmp/.X11-unix/X0: Không có tệp hoặc thư mục như vậy Lỗi: Không thể mở hiển thị: localhost: 10.0 ? Đó là bởi vì máy chủ đang cố gắng kết nối với chính nó để hiển thị GUI. Thay vào đó, bạn muốn biến HIỂN THỊ được đặt thành một địa chỉ nơi máy chủ có thể lấy máy tính của bạn. Vì vậy, nếu đó là trên mạng LAN, bạn chỉ cần đặt tên máy tính của mình. Nếu bạn đang kết nối với máy chủ trên mạng WAN, thì bạn cần chỉ định IP bên ngoài của bộ định tuyến và chuyển tiếp cổng thích hợp.

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

Nếu nó hoạt động tốt và ngừng hoạt động mà không có bất kỳ lý do chính đáng nào, có lẽ đó có thể là một trường hợp X không được kiểm soát đang chạy trong nền. Hãy đóng mà sử dụng trình quản lý tác vụ.