Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Jul 13 '11 at 18:31

This question came from our site for system and network administrators.

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 8:16
up vote 16 down vote accepted

Check the server's sshd_config (normally /etc/ssh/sshd_config), and make sure the 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.

share|improve this answer
That was it. I recommend for the benefit of others reading this later that you make your answer more explicit. (Specify the location of sshd_config, and what to change in it.) – Daryl Spitzer Jul 13 '11 at 19:05
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
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
@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 6 '15 at 8:30

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.

share|improve this answer
+1 for the Note that IP = is the local workstation's IP where you want to get the GUI – PCoder Nov 2 '13 at 10:15
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

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=""

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

share|improve this answer
This worked for me. Any idea why localhost wasn't working? – Alex Sep 24 '13 at 4:47
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=, 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 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 9 '14 at 11:38
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 6 at 2:00

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

share|improve this answer
This helped me out on my minimal debian installation, thank you very much! – binOr Jan 16 '13 at 9:44

When running UXTERM or XTERM just issue

export $DISPLAY 

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

share|improve this answer

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.


share|improve this answer

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 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.       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6 poseidon
1XX.XXX.XXX.208 poseidon

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

share|improve this answer

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
share|improve this answer

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

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .