"Can't open display" Error in X11

The X Window uses a client/server-architecture (and the server is your workstation to which you are exporting the session).

It can use a number of transport protocols, including Unix sockets and TCP/IP sockets. Which mechanism is used, is determined by the format of the DISPLAY environment variable.

• When DISPLAY does not contain a hostname, e.g. it is set to :0, Unix sockets will be used.
• When it does contain a hostname, e.g. it is set to localhost:0.0, the X client application will try to connect to the server (even localhost as in the example) via TCP/IP sockets

X has an authentication mechanism, which decides whether a client is allowed to connect to a server. As the Internet has become an increasingly hostile environment, it has become good practice to only open up services to the Internet when they are really needed. Recently in some Linux distributions, X is by default configured to listen only to localhost.

That means that default X settings become more and more defensive and thus without tuning there are more and more reasons why remote communications attempts using X initially will fail.

That's why the first time you try to run a remote X application on modern Linux distributions, it usually does not work. The most common error message by far is

"Can't open display".

xterm Xt error: Can't open display: localhost:0.0

The first thing to try is to ensure that you used a correct sequence of commands. One typical mistake is you use like xhost + on the client instead of the server (your workstation).

If you have problems the first thing to do is to see the value of the variable DISPLAY on the client. If it is not set at all or set incorrectly you need to fix that, for example

export DISPLAY=10.10.10.1:0.0

The second step to check is whether X11 server itself is accessible from the client. If firewall on the server is enables it can block X11 session. You better exclude firewall from the possible causes first. You can see this by using nmap. If port 177 (UDP) or port 6000 (TCP) are blocked you need to fix this first.

The next step is to check /var/log/messages on the server. Often if you can't connect from the client /var/log/messages contain helpful messages

ATTENTION:

In RHEL by default X11 is enabled only for localhost.

To be able to connections from the external box you need to edit the file /etc/gdm/custom.conf. The default setting for RHEL is

[security]
DisallowTCP=yes

which should be changed to false

To enable XDMCP that some users need you need to enable it.

[xdmcp]
Enable=true

After that you need to restart X11 using the command

init 3 && init 5

If in addition you want to provide ability to log as root you need security section as following

[security]
DisallowTCP=false 
AllowRemoteRoot=true

But please do it only on temp basis.

NOTES:

• To invoke terminal in RHEL, you should use command

  /usr/bin/gnome-terminal &

• Here is how the file /etc/gdm/custom.conf looks after modifications:

  # GDM configuration storage
  
  [daemon]
  
  [security]
  DisallowTCP=false
  AllowRemoteRoot=true
  
  [xdmcp]
  Enable=true
  
  [greeter]
  
  [chooser]
  
  [debug]

NEWS CONTENTS

• 20120830 : Enable XDMCP in Linux ( Jan 5, 2011 , RHEL Tech )
• 20120830 : Configuring XDMCP and GDM on Red Hat Linux by Jeff Hunter ( idevelopment.info )
• 20111104 : How to make X.org listen to remote connections on port 6000 ( Aug 3, 2011 , Ask Ubuntu )
• 20111103 : Remove -nolisten tcp argument for Xorg ( April 10, 2006 , FedoraForum.org )
• 20111103 : Remote X Server Cant Open Display ( Remote X Server Can't Open Display, Nov 03, 2011 )
• 20111103 : Remote X Apps mini-HOWTO Troubleshooting ( Remote X Apps mini-HOWTO Troubleshooting, Nov 03, 2011 )
• 20111031 : SDBX Client Produces Cant open display Error ( openSUSE )

Old News ;-)

[Aug 30, 2012] Enable XDMCP in Linux

Jan 5, 2011 | RHEL Tech

# vi /etc/gdm/custom.conf
[security]
AllowRemoteRoot=true
DisallowTCP=false

[xdmcp]
Enable=true

Note: Here "AllowRemoteRoot=true" used to allow root access.

3) Restart the gdm service
# gdm-restart

4) Check weather xdmcp port is opened or not, using netstat command
# netstat –an | grep 177
udp 0 0 0.0.0.0:177 0.0.0.0:*

[Aug 30, 2012] Configuring XDMCP and GDM on Red Hat Linux by Jeff Hunter

idevelopment.info

by Jeff Hunter, Sr. Database Administrator

• Introduction
• Configure Linux to use GUI Logins
• Granting Remote Access to the Login Manager
• Remote X Server Access from a Linux Client
• Troubleshooting
• About the Author

Most users installing Linux today choose to install and configure the X Windows System. This allows those users to access their Linux environment using a graphic (GUI) console connected to the workstation or server. An X Windows environment provides users to run X programs like xterm, OpenOffice, Mozilla Firefox and a host of other useful graphical software packages.

There are times, however, when users need to log in to a Linux machine using the graphical X Windows System from a remote computer, like a Windows PC for example. The remote Windows PC would first need to have an X Windows Server installed like Xming, Exceed Hummingbird, or my personal favorite X-Win 32.

When installing Red Hat Enterprise Linux, the system defaults to a secure configuration which does not allow remote graphical logins or remote desktop access. This article explains the configuration changes required to allow remote access to a Red Hat Enterprise Linux system (RHEL) using the X Display Manager Control Protocol (XDMCP) or GDM (GUI login).

Configure Linux to use GUI Logins
One of the first steps is to make certain the Red Hat Linux environment is configured to use a graphical (GUI) login. A Linux environment allows for either a text login or a graphical (GUI) login. This option is specified in the init script configuration file /etc/inittab. In order to allow remote graphical (GUI) logins, the environment itself must be configured for a X11 GUI login. Make certain the system is configured with the correct X11 runlevel (which in this case is runlevel 5):

#
# /etc/inittab
#

..... <SNIP> .....

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:

..... <SNIP> .....

Granting Remote Access to the Login Manager
The next step is to grant MS Windows users remote GUI access to the Red Hat Linux system. More specifically, we need to grant access to the RHEL Login Manager. Use the GDM Login Manager for RHEL 5 or higher while using the XDM Login Manager for RHEL 3 and RHEL 4.

GDM Login Manager
Users running Red Hat Enterprise Linux 5, CentOS 5, or Oracle Linux Release 5 will need to use the GDM login manager as XDM is no longer supported.

First, edit the file /etc/gdm/custom.conf and add the following two entries:

[xdmcp]
Enable=true

[security]
DisallowTCP=false
AllowRemoteRoot=true

Next, restart X Windows:

[root@racnode1 ~]# init 3
[root@racnode1 ~]# init 5

The final step is to configure the GDM login manager using the gdmsetup utility:

[root@racnode1 ~]# gdmsetup

After starting the gdmsetup utility, click the Remote tab. Under the Remote tab, change the Style pull-down menu selection from 'Remote login disabled' to 'Same as Local':

[Nov 04, 2011] How to make X.org listen to remote connections on port 6000

Aug 3, 2011 | Ask Ubuntu

(Here follows an almost verbatim copy of a self-answer from an identical question on serverfault which I'd forgotten about; askubuntu wasn't yet created).

Based on information found in this page about enabling XDCMP and the file /etc/gdm/gdm.schemas, I managed to create a /etc/gdm/custom.conf file:

# /etc/gdm/custom.conf [xdmcp] [chooser] [security] DisallowTCP=false [debug]

Take care with letter case: it won't work, if you write "disallowTCP=false"... I also changed the /etc/X11/xinit/xserverrc file to:

exec /usr/bin/X11/X

i.e. I removed the -nolisten tcp options to the X executable. I don't know if I needed to. You might want to try avoiding this edit.

If you only change the xserverrc file, X will nevertheless start with "-nolisten TCP".

After that, all that is needed is a restart of the gdm process:

sudo service gdm restart

You can verify the success as:

tzot@tzot-laptop:/etc/X11 $ netstat -an | grep -F 6000 tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp6 0 0 :::6000 :::* LISTEN 

Synopsis

So, in 10.10 this still works: create /etc/gdm/custom.conf with contents as specified above and restart gdm.

[Nov 03, 2011] Remove -nolisten tcp argument for Xorg

April 10, 2006 | FedoraForum.org

ctran

Remove -nolisten tcp argument for Xorg

--------------------------------------------------------------------------------

I'd like to have Xorg started without the "-nolisten tcp" argument. Upon logging into KDE and did 'ps -ef | grep Xorg' , I found "-nolisten tcp" arg. was used. I found the config. file /etc/X11/xdm/kdmrc and changed ServerArgsLocal=-nolisten tcp into ServerArgsLocal=

restart computer and still have above argument loaded.

Does anyone know how to remove above argument ?

ctran

jcliburn:

Try running /usr/bin/gdmsetup. Select the "Remote" tab and in the "Style" window select one of the options other than "Remote login disabled." If that doesn't do it for you, try the next suggestion.

AFAIK, gdm.conf is gone from FC5. You use /etc/gdm/custom.conf instead. The correct parameter is DisallowTCP. Add DisallowTCP=false in /etc/gdm/custom.conf to make gdm listen.

[Nov 03, 2011] Remote X Server Can't Open Display

Quote:

Hi,

I seem to have a configuration issue that is preventing me from displaying an X application using an X server on a different machine.

I would like to run an X application like this:

# export DISPLAY=10.1.60.59:0
xeyes
Error: Can't open display: 10.1.60.59:0
# xlogo
Error: Can't open display: 10.1.60.59:0

On your xserver, you have to allow incoming connections. Do a "ps -ef | grep listen", and see if it returns your Xserver daemon. If it returns a line with "-nolisten" in it (the default for lots of distros), you'll have to change your X configuration to remove the -nolisten option. I've never done it on ubuntu, so I can't be of much help there, but I'm sure there are lots of docs on the net.

After you get that going (and don't just log out...you have to either reboot or do a CTRL-ALT-BACKSPACE to restart your X server), you have to allow the connections to take place.

As root, you can either do "xhost +" (unsafe, allows ANYONE to start remote windows on your machine), or "xhost <ip address of remote machine>" (allows just that machine to fire up an X session.

[Nov 03, 2011] Remote X Apps mini-HOWTO Troubleshooting

The first time you try to run a remote X application, it usually does not work. Here are a few common error messages, their probable causes, and solutions to help you on your way.

xterm Xt error: Can't open display:

There is no DISPLAY variable in the environment, and you didn't tell the application with the -display flag either. The application assumes the empty string, but that is syntactically invalid. To solve this, be sure that you set the DISPLAY variable correctly in the environment (with setenv or export depending on your shell.

_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0

Errno 101 is ``Network is unreachable''. The application could not make a network connection to the server. Check that you have the correct DISPLAY set, and that the server machine is reachable from your client (it should be, after all you're probably logged in to the server and telnetting to the client).

_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0

Errno 111 is ``Connection refused''. The server machine you're trying to connect to is reachable, but the indicated server does not exist there. Check that you are using the right host name and the right display number.

Alternatively, it is possible that the X server was configured not to listen to the usual TCP port. To find out if this is the case, see if the X server is started with the -nolisten tcp argument, and if so, remove it.

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0

The client could make a connection to the server, but the server does not allow the client to use it (not authorized). Make sure that you have transported the correct magic cookie to the client, and that it has not expired (the server uses a new cookie when a new session starts).

[Oct 31, 2011] SDBX Client Produces Can't open display Error

openSUSE

Possible cause #1: no valid X authentication credentials

With the default X authentication mechanism, an X client needs to have access to a valid X session cookie (which is, essentially, a shared secret between the X server and its clients).

When a user switches to a different user using the su command, X session cookies are not transferred and thus the user cannot start X applications under the user id to which he or she switched.

Solution to the authentication credentials problem: sux

Instead of su, use sux to switch user id. Like su, sux switches to a different user id. Unlike su, it ensures that the id being assumed is given access to the X session cookie so that X applications can be started.

Possible cause #2: the X server isn't listening

A DISPLAY setting is used which causes the X client application to attempt to use TCP/IP sockets rather than Unix sockets. This attempt fails because in recent releases of SUSE Linux the X server does not listen to TCP/IP sockets by default, for security reasons.

Solution for local connections

When, as is mostly the case, the X server and the X client application are running on the same system, do not use a hostname in the DISPLAY settings. Use DISPLAY=:0.0; export DISPLAY.

Preferred solution for non-local X connections: ssh

When the X server and the X client application are to run on different systems, there are two ways to enable the connection.

The first is to connect to the remote system using ssh -X. SSH (secure shell) is a de facto standard remote access mechanism that uses cryptographic techniques to secure connections against wiretapping and session hijacking. The -X option to ssh tells it to try to set up a tunnel through which X11 connections can be forwarded.

Alternative solution for non-local X connections: enable TCP/IP socket connections

Another solution is to enable TCP/IP sockets for X11 as follows:

• Set DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" in the /etc/sysconfig/displaymanager file
• Running /sbin/SuSEconfig to propagate that setting
• Restart your display manager through /usr/sbin/rcxdm restart

Enabling a network service on a port increases the ways a system may be attacked by a cracker. As a good security practice, when a network service (like X connections via TCP port 6000) is enabled, access to it should be restricted to authorized systems only, e.g. via iptables rules.

As this solution is more cumbersome than using ssh -X, in particular from a security management point of view, it should only be used when ssh -X isn't an option (e.g. due to interoperability issues with legacy systems).

Recommended Links

Softpanorama Recommended

Top articles

Sites

• SDBX Client Produces Can't open display Error - openSUSE
• Remote X Apps mini-HOWTO contains more information on how to run X applications remotely in a secure fashion, including the use of xauth to implement access control based on a shared secret (a so called magic cookie) rather than the insecure hostname or username based access control using xhost.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 28, 2019