Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

X Client  "Can't open display" Error

The X Window  uses a client/server-architecture that 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.  That means that default X settings become more and more defensive and thus without tuning more and more remote communications attempts initially will fail.

That's why the first time you try to run a remote X application on modern Linux distributions like Suse 10 SP2, it usually does not work. The most common error message by far is "Can't open display". In this case an X client application, for example xterm, reports an error Can't open display on startup, for instance 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 like xhost + on the server and correct export DISPLAY command on the client. You  also should enable listening to the TCP port by running gdmsetup as root or editing the file  gdm.conf .  The relevant setting is

DisallowTCP=yes

If you want X to listen the TCP/IP you need change this to false

Old News ;-)

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).

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

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.