When I am online, I get following error and the tool does not start:

[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0

But everything is OK when I am not a superuser. Why that?


[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified

any suggestion?


[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost:  unable to open display ":0.0"
  • This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account. – uprego Jan 31 '14 at 9:23
  • Did both , see the edit above – msz Jan 31 '14 at 9:28
  • It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X. – uprego Jan 31 '14 at 9:42
  • @galegosimpatico: why would launching a dbus server solve this issue? – Bananguin Jan 31 '14 at 9:47
  • When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux) – Bananguin Jan 31 '14 at 9:49

An X program needs two pieces of information in order to connect to an X display.

  • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.

  • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.

See Open a window on a remote X display (why "Cannot open display")? for more details.

In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.

If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.

If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.

If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:

XAUTHORITY_COPY=$(umask 077; mktemp)
cat "${XAUTHORITY:-~/.Xauthority}" "$XAUTHORITY_COPY"
  • 1
    I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~ – Can Geliş Feb 3 '15 at 8:58
  • XAUTHORITY for me was set as a file that no longer existed: – pbhj Jan 11 '16 at 13:28

You are running xhost as root !

run xhost as the normal user xhost + , then become root then try again.

btw as others have pointed out xhost + permits any user from any host

  • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +! – Gilles Jan 31 '14 at 22:48
  • Understand, that's a good point. Thanks for your advice. – X Tian Feb 1 '14 at 2:04

XAUTHORITY for me was set as a file that no longer existed:



So I did


and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)


Run as normal user

xhost + localhost

then enable super user by

sudo su 

finally go to server example

cd /usr/local/Ampps

finally run ./Ampps

thank me in 2020

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.