12

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?

Edit

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

any suggestion?

Also 

[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost:  unable to open display ":0.0"
Gilles 'SO- stop being evil'
  • 829,060
msz
  • 301
  • 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. – 41754 Jan 31 '14 at 09:23
  • Did both , see the edit above – msz Jan 31 '14 at 09: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. – 41754 Jan 31 '14 at 09:42
  • @galegosimpatico: why would launching a dbus server solve this issue? – Bananguin Jan 31 '14 at 09: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 09:49
  • @Bananguin The dbus relaunch from a terminal works around X connection problems in some versions of Debian. But it's true that this users' prompt hints the use of a non Debian family GNU/Linux distribution (maybe Fedora?). – 41754 Jan 31 '14 at 10:00
  • @Bananguin: i am getting :0.0, when i give echo $DISPLAY – msz Jan 31 '14 at 10:28
  • @Bananguin: but i could not understand second part of your question. – msz Jan 31 '14 at 10:30
  • IIRC, xhost should be run from inside the X server as the user who is running the X session. Is that root as well? – njsg Jan 31 '14 at 10:35
  • Using xhost + is the equivalent of "opening a huge security hole big enough for anyone to drive a bus through". – Jenny D Jan 31 '14 at 11:41
  • @galegosimpatico No, neither of these will help. (xhost + might on some setups, but if it does, you don't want to use it: it means “allow anybody to do anything with my account”.) – Gilles 'SO- stop being evil' Jan 31 '14 at 22:39
  • Oh yeah, running xhost + exposes root and user login passwords as long as samba passwords. And God kills 314 kittens too. – 41754 Feb 01 '14 at 17:19

5 Answers5

16

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"
XAUTHORITY="$XAUTHORITY_COPY" su
rm "$XAUTHORITY_COPY"
unset XAUTHORITY_COPY
Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
6

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

X Tian
  • 10,463
1

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

$ echo $XAUTHORITY

/tmp/xauth-1000-_0

So I did

unset XAUTHORITY

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

pbhj
  • 413
0

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

Mr Mash
  • 1
0

This worked for me in fedora 30

xhost local:root
sudo QT_X11_NO_MITSHM=1 /usr/bin/unetbootin
Gang
  • 353