Cannot connect to X server :0.0 as superuser
Clash Royale CLAN TAG#URR8PPP
up vote
7
down vote
favorite
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"
x11 su xauth
 |Â
show 7 more comments
up vote
7
down vote
favorite
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"
x11 su xauth
This is a classic. You may doexport $(dbus-launch)
or usexhost [+]
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 doesecho $DISPLAY
show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for exampleps faux
)
â Bananguin
Jan 31 '14 at 9:49
 |Â
show 7 more comments
up vote
7
down vote
favorite
up vote
7
down vote
favorite
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"
x11 su xauth
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"
x11 su xauth
x11 su xauth
edited Jan 31 '14 at 22:48
Gilles
515k12210241553
515k12210241553
asked Jan 31 '14 at 9:21
msz
56229
56229
This is a classic. You may doexport $(dbus-launch)
or usexhost [+]
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 doesecho $DISPLAY
show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for exampleps faux
)
â Bananguin
Jan 31 '14 at 9:49
 |Â
show 7 more comments
This is a classic. You may doexport $(dbus-launch)
or usexhost [+]
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 doesecho $DISPLAY
show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for exampleps faux
)
â Bananguin
Jan 31 '14 at 9:49
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
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
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
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
@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
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
 |Â
show 7 more comments
4 Answers
4
active
oldest
votes
up vote
10
down vote
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 theDISPLAY
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 cookie123456
âÂÂ. The X authority file is normally indicated in theXAUTHORITY
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
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
add a comment |Â
up vote
2
down vote
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 thatxhost
does not work. If it does, then at least runxhost +localhost
, notxhost +
!
â 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
add a comment |Â
up vote
0
down vote
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
)
add a comment |Â
up vote
0
down vote
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
New contributor
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
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 theDISPLAY
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 cookie123456
âÂÂ. The X authority file is normally indicated in theXAUTHORITY
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
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
add a comment |Â
up vote
10
down vote
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 theDISPLAY
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 cookie123456
âÂÂ. The X authority file is normally indicated in theXAUTHORITY
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
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
add a comment |Â
up vote
10
down vote
up vote
10
down vote
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 theDISPLAY
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 cookie123456
âÂÂ. The X authority file is normally indicated in theXAUTHORITY
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
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 theDISPLAY
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 cookie123456
âÂÂ. The X authority file is normally indicated in theXAUTHORITY
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
edited Apr 13 '17 at 12:37
Communityâ¦
1
1
answered Jan 31 '14 at 22:47
Gilles
515k12210241553
515k12210241553
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
add a comment |Â
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
1
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
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
XAUTHORITY for me was set as a file that no longer existed:
â pbhj
Jan 11 '16 at 13:28
add a comment |Â
up vote
2
down vote
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 thatxhost
does not work. If it does, then at least runxhost +localhost
, notxhost +
!
â 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
add a comment |Â
up vote
2
down vote
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 thatxhost
does not work. If it does, then at least runxhost +localhost
, notxhost +
!
â 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
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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
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
edited Jan 31 '14 at 12:56
answered Jan 31 '14 at 12:48
X Tian
7,45111936
7,45111936
Many modern systems are set up so thatxhost
does not work. If it does, then at least runxhost +localhost
, notxhost +
!
â 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
add a comment |Â
Many modern systems are set up so thatxhost
does not work. If it does, then at least runxhost +localhost
, notxhost +
!
â 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
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
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
Understand, that's a good point. Thanks for your advice.
â X Tian
Feb 1 '14 at 2:04
add a comment |Â
up vote
0
down vote
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
)
add a comment |Â
up vote
0
down vote
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
)
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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
)
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
)
answered Jan 11 '16 at 13:30
pbhj
19818
19818
add a comment |Â
add a comment |Â
up vote
0
down vote
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
New contributor
add a comment |Â
up vote
0
down vote
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
New contributor
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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
New contributor
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
New contributor
New contributor
answered 2 mins ago
Dev Mash E
1
1
New contributor
New contributor
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f111831%2fcannot-connect-to-x-server-0-0-as-superuser%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
This is a classic. You may do
export $(dbus-launch)
or usexhost [+]
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 exampleps faux
)â Bananguin
Jan 31 '14 at 9:49