View Full Version : $DISPLAY not working

30th November 2017, 03:22 PM
Hi all - first post here! I'm a longtime Linux user, and am actually surprised to be encountering an issue on what should be a trivial problem. I'm simply trying to run a GUI program (for now, just trying with xterm!) on a remote host. Simple, right? It's slightly more complicated than usual in that I'm running it from a docker session inside a screen session, so I can't just "ssh -Y" in; I need to manually set $DISPLAY. Which should be simple. But it's just not working. More to the point, it doesn't work outside the docker session either, so it clearly has nothing to do with docker (although I ultimately need to get it to work in docker, of course!).

Local host:
Remote host: chmmr

If I do:

ssh -Y chmmr

.... then I can run xterm just fine. DISPLAY is set to "localhost:13.0", which I find a bit odd (13? I only have one X session open on, but okay). If I however run:

ssh chmmr

... then nothing I do seems to work to not get a "xterm: Xt error: Can't open display:" error. Each export display starts "export DISPLAY="; after that I've tried pretty much everything. "", "0", "0.", "0.0", ".0", "13", "13.", "13.0", etc. I can ssh just fine from chmmr back to I've run "xhost +" on I've shut off iptables on But nothing ever works.


30th November 2017, 05:06 PM
Are you using Wayland?

30th November 2017, 06:50 PM
Linux version 4.11.6-301.fc26.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 7.1.1 20170526 (Red Hat 7.1.1-2) (GCC) ) #1 SMP Tue Jun 20 16:17:33 UTC 2017 Linux version
4.11.12-100.fc24.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Fri Jul 21 17:35:20 UTC 2017

1st December 2017, 12:10 PM
These days Fedora uses Wayland by default, this is a replacement for X11/Xorg. As $DISPLAY is an X11 specific thing I wouldn't expect it to work in Wayland. You can tell if you're running wayland by running "loginctl" from the command line to list sessions and then "loginctl show-session <N> -p Type" where <N> is the session number from the first command.

1st December 2017, 03:52 PM
If you want to switch back to Xorg, I suggest [yum group install "Xfce Desktop"] , then when logging in, choose that from the session list instead of GNOME.

Oh, but also, do this:
systemctl disable gdm
systemctl enable lightdm

then reboot.

1st December 2017, 04:39 PM
If you want to switch back to Xorg, I suggest [yum group install "Xfce Desktop"] , then when logging in, choose that from the session list instead of GNOME.

Suggesting to stop using Gnome is a bit drastic, there is a Gnome-classic (i.e: xorg) session available... I'm a Window Maker user myself but I wouldn't recommend it for most users. Editing /etc/gdm.custom.conf will allow gdm to be used without Wayland, although lxdm is another option as well.

1st December 2017, 06:29 PM
There is `GNOME Classic` but there is also a `GNOME on Xorg` session. Two different things. I am not sure on what Gnome Classic runs on thought.


1st December 2017, 09:08 PM
Wow, okay, I just assumed Wayland was a Fedora release name - I had no clue that it was an xorg branch. Lol, I began with X long before it was xorg, I really need to keep up with these things better ;)

On both chmmr and, it says Type=x11. So that means xorg, no?

Re, Gnome / xfce: LOL, no way I'm switching desktops (I use KDE), but thanks ;)

I should probably reiterate: if I do "ssh -Y chmmr" I can run GUI programs (like, say, xterm) just fine. So it clearly is possible. I just can't get it to work by hand-tweaking the $DISPLAY variable, which seems to be what would be needed for running a GUI program in the docker session.,

3rd December 2017, 07:29 PM
No ideas?

4th December 2017, 01:03 AM
While it used to be possible to simply set the DISPLAY to your workstation's display, that is now a bit more difficult with the security protocols.
Quoting from the man page for ssh X11 forwarding:

The DISPLAY value set by ssh will point to the server machine, but with a display number greater than
zero. This is normal, and happens because ssh creates a “proxy” X server on the server machine for
forwarding the connections over the encrypted channel.

ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will
generate a random authorization cookie, store it in Xauthority on the server, and verify that any for‐
warded connections carry this cookie and replace it by the real cookie when the connection is opened.
The real authentication cookie is never sent to the server machine (and no cookies are sent in the

I think you will need to study the X security stuff: "man Xsecurity" should get you started.

4th December 2017, 09:44 PM
I'm just going to have to try to find another way to work around this. I can't believe something that used to be so simple has been made so complicated :Ţ That's not progress.