How do I fix a "cannot open display" error when opening an X program after ssh'ing with X11 forwarding enabled?

Question

After launching the X11 app (XQuartz 2.3.6, xorg-server 1.4.2-apple56) on my Mac (OS X 10.6.8), opening an terminal in X11 and running xhost +, I then ssh -Y to my Ubuntu 10.04 VM (running on VMware Fusion). When I run gedit .bashrc (for example), I get:

(gedit:9510): Gtk-WARNING **: cannot open display:

set | grep DISPLAY returns nothing.

But if I ssh -Y into my Ubuntu 11.04 machine, gedit .bashrc works. echo $DISPLAY returns "localhost:10.0".

I tried export DISPLAY=localhost:10.0 while sshed into my VM and then running gedit .bashrc, but I get:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

What could be different in the configuration of the two difference Ubuntu machines that would explain why one works and the other doesn't?

Update: As suggested by Zoredache in the comment below, I ran sudo apt-get install xbase-clients, but I continue to have the same problem.

Does the Ubuntu 10.04 box have the proper tools for X11 installed? Install xbase-clients, if it isn't installed already. — Zoredache, Jul 13 '11 at 18:22
I installed it but still have the same problem. (See above.) — Daryl Spitzer, Jul 13 '11 at 18:29
Yes. Just to be sure, I restarted the VM (and reconnected through SSH afterward). — Daryl Spitzer, Jul 13 '11 at 18:38
Maybe try passing the -vv option to ssh when you connect, this prints verbose debug messages, you should see several comments about X11 forwarding while connecting. — Zoredache, Jul 13 '11 at 18:43
@jcrawfordor You did check the `X11Forwarding` on the ubuntu one, and that you have `xbase-clients` installed and that you can start Xapps on the mac on the terminal you're making ssh connection from. (Check that `$DISPLAY` is set on the terminal you run ssh **from**. — Manwe, Feb 27 '12 at 08:16
Note that I'm ready to accept DefK's answer, after it's modified to include both enabling X11 forwarding and installing base-clients. (Or I'll accept a new answer if someone else takes the time to explain both.) — Daryl Spitzer, Feb 27 '12 at 19:10
In my case it was just a matter of upgrading the XQuartz version of MacOS — Waruna Ranasinghe, Dec 29 '16 at 18:20
In my case, I needed to restart XMing on Windows. X-forwarding was always working until it stopped for unknown reasons. I had no idea why `$DISPLAY` would output `localhost:10.0` either. In Putty, my X11 location is set to `localhost:0.0`. Force quitting XMing and restarting fixed the issue without changing anything. — Shailen, Mar 01 '18 at 17:14
I also have the same error and setting DISPLAY won't fix it. ```eog new.png Failed to connect to Mir: Failed to connect to server socket: No such file or directory Unable to init server: Could not connect: Connection refused (eog:9994): Gtk-WARNING **: cannot open display: :0``` — skyuuka, Aug 18 '19 at 09:22
@DarylSpitzer I had the same issue, the solution was that an empty configuration file was missing, but was required to be there ... touch /root/.Xauthority ... put that file in the ~/ location for whatever user you are attempting to forward X through. — oemb1905, Aug 12 '21 at 18:55
By the Way: to check $DISPLAY use `$ echo $DISPLAY`, not just `$ $DISPLAY` — xgqfrms, Apr 14 '23 at 10:30

harrymc · Answer 1 · 2018-08-03T07:26:02.837

96

From xhost+ : How to Fix “Cannot Open Display” Error While Launching GUI on Remote Server:

Answer: You can fix the “cannot open display” error by following the xhost procedure mentioned in this article.

Allow clients to connect from any host using xhost+

Execute the following command to disable the access control, by which you can allow clients to connect from any host.
$ xhost +
access control disabled, clients can connect from any host

Enable X11 forwarding

While doing ssh use the option -X to enable X11 forwarding.
$ ssh username@hostname -X
Enable trusted X11 forwarding, by using the -Y option,
$ ssh username@hostname -Y
Open GUI applications in that host

After opening ssh connection to the remote host as explained above, you can open any GUI application which will open it without any issue.

If you still get the “cannot open display” error, set the DISPLAY variable as shown below.
$ export DISPLAY='IP:0.0'
Note: IP is the local workstation’s IP where you want the GUI application to be displayed.

edited Aug 03 '18 at 07:26

answered Feb 21 '12 at 08:47

harrymc

455,459
31
526
924

25

+1 for the Note that **IP = is the local workstation's IP where you want to get the GUI** – PCoder Nov 02 '13 at 10:15
5

For those having similar issues on OS X, also make sure you have XQuartz installed, otherwise none of these fixes help. (OP's question shows he has XQuartz, so this is more a side note to those having similar issues as I was) – Dolan Antenucci May 28 '14 at 21:49
3

Note that running `xhost +` is very unsecure and should not be used! As Stefan Rogin mentioned, the attacker can then from the host connect to your XSession, read all you type, or even alter the screen you see. – jirislav May 13 '18 at 08:38
the last one `export Display=IP:0.0` did it for me – WestCoastProjects Oct 18 '19 at 22:41
3

For whatever reason, `-Y` got it working, `-X` doesn't. – ibic Oct 26 '19 at 14:44
+1 for "ssh ... -X" – Adrian Aug 05 '20 at 11:46

score 67 · Accepted Answer · edited Oct 14 '20 at 12:46

67

Check the server's sshd_config (normally /etc/ssh/sshd_config), and make sure X11Forwarding option is enabled with the line

X11Forwarding yes

If X11Forwarding is not specified, the default is no on the Debian machines I have available to check.

edited Oct 14 '20 at 12:46

pevik

580
4
13

answered Jul 13 '11 at 18:54

DerfK

1,161
9
13

8

I discovered after setting up another Ubuntu VM, that I need to both install xbase-clients and enable X11Forwarding. Update your answer to include both and I'll accept it. – Daryl Spitzer Jul 13 '11 at 19:21
1

Interesting. At least on the new install of 10.04 that I did this morning X11Forwarding was enabled by default. The Ubuntu guys must be messing around with defaults again. – Zoredache Jul 13 '11 at 19:50
77

@DerfK, in my system "X11Forwarding yes" was there already still I am getting error as, **(gedit:8381): Gtk-WARNING **: cannot open display:** in such cases – A J Oct 06 '15 at 08:30
1

On Debian you might have to install package xauth, then log again. – comte Aug 07 '18 at 09:40
$ ssh username@hostname -Y this worked for me – MarcoZen Jul 31 '19 at 21:32
7

not working here, X11Forwarding set to yes. xauth installed. – RichieHH Mar 21 '20 at 16:06
10

This should not be the accepted answer - the question clearly specified that X11 forwarding was already enabled. Total waste of time ... – oemb1905 Aug 12 '21 at 18:56
it's enabled and still this error! – user924 Oct 14 '21 at 08:44

score 29 · Answer 3 · answered Jun 29 '12 at 20:44

29

I've had this problem when logging into a Ubuntu VM from Mac OS X as well -- it doesn't seem to like 'localhost' in the display variable for some reason. So set the IP manually, as harrymc suggests:

export DISPLAY="127.0.0.1:10.0"

Then X11 programs should be fine. It doesn't seem like it should be necessary to tell the OS that localhost and 127.0.0.1 are equivalent, but it works, at least.

answered Jun 29 '12 at 20:44

SpinUp __ A Davis

662
7
10

This worked for me. Any idea why localhost wasn't working? – Alex Sep 24 '13 at 04:47
3

BINGO! I've been stuck by that problem for some time... I connected by SSH and couldn't launch Gtk programs (plain X11, like "xeyes", worked however). DISPLAY was correct. Actually, the resolution of "localhost" wasn't! If I set manually DISPLAY=127.0.0.1:10.0, or DISPLAY=::1:10.0 it does work. Editing /etc/hosts seems to have no effect; and DNS is correctly configured ("dig localhost" correclty report both 127.0.0.1 and ::1) So, it seems to be a bug in whatever does DNS resolution for X11 connections in Gtk (gtk? gdk? glib? other?). – Pablo Saratxaga Feb 09 '14 at 11:38
1

On a Debian install for the Beagle Bone Black, /etc/host was not set to readable by anyone but root. This caused the symptoms reported here. Made /etc/hosts readable by all, and it worked fine. – Daniel Mar 06 '16 at 02:00
17

My error is now `unable to open display"127.0.0.1:10.0"` – dustytrash Apr 05 '20 at 21:45
1

more than likely this answer works because `127.0.0.1 localhost` is not defined within the `/etc/hosts` file as most debian based distros setup `127.0.1.1 localhost` thus when you manually set this env var after logging in, things begin to work. I added the above entry to `/etc/hosts` and i no longer have to manually set the `DISPLAY` env var after logging in. – ipatch Oct 28 '20 at 19:31

score 18 · Answer 4 · answered Oct 22 '12 at 07:59

18

I had this problem with my CentOS KVM server, I was missing the "xauth" program.

answered Oct 22 '12 at 07:59

Joril

2,020
1
26
33

2

This helped me out on my minimal debian installation, thank you very much! – binOr Jan 16 '13 at 09:44
xauth installed, still have this error. – towry Jan 25 '21 at 01:38

score 17 · Answer 5 · edited May 23 '17 at 12:41

If you have this problem after some time when running with -X arg. or just ForwardX11 in /etc/ssh/ssh_config, then run $ ssh username@hostname -Y, to enable trusted X11 forwarding, don't know the exact cause but I'm guessing with -X some features expire after some time, probably to increase security.

Here is what I found online :

If you use ssh -X remotemachine the remote machine is treated as an untrusted client. So your local client sends a command to the remote machine and receives the graphical output. If your command violates some security settings you'll receive an error instead.

But if you use ssh -Y remotemachine the remote machine is treated as trusted client. This last option can open security problems. Because other graphical (X11) client could sniff data from the remote machine (make screenshots, do keylogging and other nasty stuff) and it is even possible to alter those data.

If you want to know more about those things I suggest reading the Xsecurity manpage or the X Security extension spec. Furthermore you can check the options ForwardX11 and ForwardX11Trusted in your /etc/ssh/ssh_config.

sources:

This is what worked for me. Thank you! – Artichoke May 09 '22 at 22:13 — Artichoke, May 09 '22 at 22:13

Color · Answer 6 · 2018-02-05T08:16:10.980

11

Just Tested On My Mac, Other Systems Might Be OK:

Allow clients to connect from any host using xhost+

$ xhost +
You should have an environment that support X11 display

[Mac System] Install X11 for mac https://www.xquartz.org/
You should let your ssh-server forward x11 display

update /etc/ssh/sshd_config and set X11Forwarding yes, then restart your ssh server
You should let your ssh session forward x11 display with -X parameter

$ ssh -X user@ip
How to open X11 app in PyCharm?
- open a ssh session that support X11 display(remember to keep this session)
- run echo $DISPLAY in that ssh session
- set DISPLAY environment variable for your PyCharm

edited Feb 05 '18 at 08:16

answered Aug 30 '17 at 11:36

Color

211
2
3

1

Why is this different or why should it be preferred over any of the other answer? Please explain if you can with a simple [edit]. You can do it!! – Vomit IT - Chunky Mess Style Aug 30 '17 at 12:34
@McDonald's Thanks, updated with more details. – Color Sep 04 '17 at 02:58

score 9 · Answer 7 · edited Sep 01 '17 at 01:32

I had to put in /etc/ssh/sshd_config the following:

X11UseLocalhost no

Rather then setting it "yes". Strange if the default is "NO" Users using putty with XMing under Windows. I use straight ssh over Fedora. Occasionally it would start giving us

error can't open display localhost

Reboot of the server would usually fix it but this is stupid. Did the above, restarted the service sshd on the server and presto new connections working fine again.

score 6 · Answer 8 · answered Jul 08 '19 at 17:25

6

This setup works for me:

Local (64 bit Cygwin on Windows 10) DISPLAY=:0

Server (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

These settings were found by clicking "X applications menu on :0" in taskbar and selecting System Tools > Terminal

answered Jul 08 '19 at 17:25

qwr

657
8
13

This works for me (XQuartz on macOS Mojave, X11 Client on Debian 10). Thanks! – Arnie97 Nov 27 '19 at 17:52
Same as above. It worked for XQuatz + Debian Unstable. I used `DISPLAY=:10.0` – muammar Jun 14 '22 at 16:08

score 5 · Answer 9 · edited Jul 10 '12 at 21:28

5

When running UXTERM or XTERM just issue

export $DISPLAY

The variable will be there. Then just set it and export it.

edited Jul 10 '12 at 21:28

slhck

223,558
70
607
592

answered Jul 10 '12 at 21:26

Oracle2066

51
1
1

score 3 · Answer 10 · edited Mar 19 '15 at 00:23

3

I also had this problem with Solaris 10 and found that the listener was not set up.

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop  options/tcp_listen = true

edited Mar 19 '15 at 00:23

G-Man Says 'Reinstate Monica'

7,678
22
41
87

answered Mar 18 '15 at 22:52

Doug Somers

31
1

score 2 · Answer 11 · answered May 30 '18 at 13:40

2

open terminal $ ssh username@hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY="127.0.0.1:10.0" all should work.

answered May 30 '18 at 13:40

Kenny Gichuhi

21
1

Thanks. Works for my special case when `DISPLAY='localhost:10.0'` is not working. – xpt Dec 09 '18 at 22:42
stil not working – towry Jan 25 '21 at 01:40

score 1 · Answer 12 · answered Jun 10 '16 at 11:56

1

I just found a nice hiccup in my setup that prevented x forwarding: My firewall was blocking all connections from localhost, thus preventing the tunnel to be reached

answered Jun 10 '16 at 11:56

Pelle

276
2
3

Oliver · Answer 13 · 2017-05-01T17:45:31.867

1

If you happen to be using Konsole simply switch to another terminal emulator such as Xfce Terminal and try again using root.

edited May 01 '17 at 17:45

answered May 01 '17 at 04:13

Oliver

111
3

score 1 · Answer 14 · answered Jul 15 '14 at 15:13

On CentOS 6.5, I suddenly lost remote X-programs access after messing with /etc/hosts. Same symptom of empty $DISPLAY variable (no help setting/exporting it manually).

The 127.0.0.1 entry pointing to the actual hostname is necessary; in fact the order seems to be also relevant (put last & it won't work...)

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

After fixing this, xeyes, xclock and other X test toys are working again, therefore my needed virt-manager is also back on line.

score 0 · Answer 15 · answered Apr 15 '20 at 18:33

0

Something else to check is if you are in an elevated prompt or are using another user's bash.

If you have run sudo su and try to open an X11 window, that won't work until you revert back to your original ssh bash.

answered Apr 15 '20 at 18:33

Gabriel Fair

3,605
12
35
65

This simply is not true. It IS possible. as user1, `echo $DISPLAY` and `xauth list $DISPLAY`. As user2, `xauth add (result line copied from xauth list above)` and `export DISPLAY=(results of echo command above). – Jeter-work Feb 24 '22 at 17:05

score 0 · Answer 16 · edited Oct 12 '20 at 14:13

0

I ran into this problem often and finally I figured out the issue and resolved it. Here is the checklist.

Make sure all the following conditions are satisfied.

X11Forwarding yes (check in /etc/ssh/sshd_config)
ssh -Y [email protected](important: -Y)

If you have to make multiple hops to reach your destination server, make sure to use ssh -Y ... at all ssh connections. This is one of the reasons display failed for me because I simply used ssh username@remote_host.de at one of the connections.

edited Oct 12 '20 at 14:13

pevik

580
4
13

answered Jun 10 '20 at 00:07

kmario23

153
1
7

still not working. – towry Jan 25 '21 at 01:41
I have had this issue with a raspberry pi (debian) and the memory was full. Clearing all the /media/usb0 files out solved the problem – nerak99 Mar 07 '21 at 16:49

How do I fix a "cannot open display" error when opening an X program after ssh'ing with X11 forwarding enabled?

16 Answers16

Linked