Why can't I run GUI apps as root: "No protocol specified"?
Solution 1
Accessing the X server requires two things:
- The
$DISPLAY
variable pointing to the correct display (usually:0
) - Proper authentication information
The authentication information can be explicitly specified via $XAUTHORITY
, and defaults to ~/.Xauthority
otherwise.
If $DISPLAY
and $XAUTHORITY
is set for your user, sudo
will set them for the new shell, too, and everything should work fine.
If they are not set, they will probably default to the wrong values and you cannot start and X applications.
In Debian $XAUTHORITY
is usually not set explicitly. Just add
export XAUTHORITY=~/.Xauthority
to your .bashrc
or explicitly say XAUTHORITY=~/.Xauthority sudo ...
and everything should work.
You can also use xauth list
to check whether proper authentication information are available.
Solution 2
I had the same question as you but for a normal user. Let's say I want to start firefox using the user account foo. I'm logged in as bar:
[bar@localhost ~]$ sudo -u foo -H firefox
Sadly that command failed with the same error as in the question (i.e. no protocol specified & cannot open display)
My solution was to simply add the user foo to the list of authorised access to the X server.
xhost si:localuser:foo
And that was it, I was then able to launch Firefox (and other X application) using sudo
and the user foo.
Background: On X Window, there is a client/server architecture. When you launch an application you request the X server authorisation to display it. By default once you open a session (you graphically login), you (your user) are obviously allowed to commmunicate with the server and display applications. Other users do not have this permission unless you specify it. xhost
is a tool to manipulate the list of permissions. The si
indicates that the rule is server side and it authorise the local user foo
to display applications. X Window is very powerful in this regard and you can display remote applications locally by playing with the DISPLAY
environment variable and xhost
(but not limited to them). In older times, when people typed xhost +
and implicitely allowed everyone to use their X session, it was possible to display application on their screen for pranks ;-) not so much nowadays as people are less and less using X Window client/server architecture (at least for what I observe in the past 10 yers).
PS: I did this in order to launch Firefox in a kind of "jail" (to avoid a vulnerability like for pdf.js in the future). But I quickly found out that calling Firefox via sudo won't allow it to access audio nor the video hardware. But there is one guy which explain clearly how to activate video hardware acceleration and audio when calling Firefox via sudo. YMMV with these instructions, e.g. I still have a permission denied with audio but video is fine (tested on Fedora 22 with SELinux ON).
Solution 3
You can either
Specify the display to be used on the command line, by adding -display :0.0
or
Set up the environment variable in root's login script (one of .bashrc, .profile, .bash_profile ...).
export DISPLAY=:0.0
You can check whether it's set,
$ env |grep DISPLAY
DISPLAY=:0.0
To open up your display for all users from all hosts as your normal user you can do this with :
xhost +
Edit: Thanks and credit to @Toby Speight for his comment below for the more targeted suggestion, instead of opening it up for anybody.
xhost +si:localuser:root
Solution 4
Given that you're on Debian, the simple and supported solution is to arrange for sudo
to copy your X11 authorization credentials. pam_xauth
is included in the libpam-modules
package for exactly this purpose; to use it, you just need to add
session optional pam_xauth.so
to your /etc/pam.d/sudo
file. You may also choose to add it to su
, too. For full information, consult the pam_xauth
man page, of course.
Solution 5
What helped me:
You can
xauth generate :0 . trusted
on theuser
side, which will generate a newMIT-MAGIC-COOKIE-1
Check the newly created Key with
xauth list
asuser
androot
(they should be the same if yourXAUTHORITY
variable is pointing to the same file.Voila,
root
will access any X application from terminal, but only temporarily.
To make it permanent, see @Huygens' answer!
Related videos on Youtube
Octopus
Updated on September 18, 2022Comments
-
Octopus over 1 year
I installed Debian onto my machine last night. Now, I don't understand why I can't run GUI apps from a terminal when running as root.
For example:
sudo -i glxgears
Generates the following output:
No protocol specified Error: couldn't open display :0
But when I first open the terminal I can run
glxgears
from the user account. It's only after I dosudo -i
that the problem crops up. This happens for any GUI app that I try to run.I think it's probably related to X11, but I'm not sure.
-
Admin over 9 yearsstackoverflow.com/a/20612084 this worked perfectly for me.
-
Kayofeld about 5 yearsAbout Wayland, just in case: Arch Wiki, "sudo with graphical apps doesn't work on wayland ".
-
Matthias Braun about 2 years@Alexey: The ArchWiki also contains a workaround using xhost. I tried running LinSSID and sparrow-wifi on Sway (Wayland) which worked after executing
xhost +si:localuser:root
, discussion here.
-
-
Tomas Tomecek about 9 years
xauth info
shows path to authority file -
Anthon over 7 yearsThis will give
cp: cannot stat ‘/home/user/.Xauthority’: No such file or directory
on any of the 10+ Debian based machines I have access to. -
nyxee over 7 years
xhost +
worked for me too, only that they forgot to mention we should run it from the authorizing user's terminal, not from a terminal undersudo su
. -
Kalle Richter over 6 yearsIn my case
foo
wasroot
, i.e. I had to runxhost si:localuser:root
on Ubuntu 17.10. -
v6ak about 6 yearsThis gives a little context (e.g., you silently expect some current directory) and you don't mention side effects like troubles when doing so in multiple X11 instances. I think this way is a bit hacky.
-
cbcoutinho about 6 yearsWhere do you add the
xhost si:localhost<user>
command? If no users are logged on, then no one has an X server available to give permission to. -
Huygens about 6 years@cbcoutinho The above use case is when someone is logged on and wants to run an XWindow application as someone else on the same host. If you explain your use case (what is the problem you would like to solve) then I can potentially help you.
-
cbcoutinho about 6 years@Huygens I have a workstation for simulating fluids that is also equipped with a GPU. I render the visualizations with
ParaView
, a program built onvtk
, usually on the workstation itself.ParaView
also provides a secure headless client/server rendering model through ssh, which I would like to take advantage of remote instead of using VNC. Without logging into the workstation and executingxhost
, I can't utilize the GPU. That means that I can't reboot the machine remotely and still have access to the GPU. -
cbcoutinho about 6 years@Huygens thanks for getting back to me. Regarding the rendering,
ParaView
has a server available with an offscreen rendering flag. Adding a dummy user with 'auto login' solved my problem -
Melroy van den Berg about 6 years
xhost +
fixed my problem -
michas about 6 yearsBe aware that
xhost +
completely deactivates authentication and allows everyone to access all application on your screen... -
marinara about 5 yearsfor debian, do I type the XAUTHORITY export as root? because it's not working on deb10? I login with sudo su
-
michas about 5 years@marinara use
sudo -i
instead ofsudo su -
. -
David Cowden almost 5 yearsNow that Debian 10 (Buster) is out, how do you do this with
wayland
? -
David Cowden almost 5 years
xhost +si:localuser:root
seems to work similar. -
interestedparty333 over 4 yearslogged in as myself (as opposed to root), running
xhost si:localuser:root
worked for me -
Seff over 3 yearsOn Ubuntu 18, I had to
export XAUTHORITY=/run/user/1000/gdm/Xauthority
-
X.LINK over 3 yearsThat is the most correct and underrated answer, since it also fixes a lot of other related issues and is a far cleaner solution. Putting
session optional pam_xauth.so
to/etc/pam.d/sudo
and/etc/pam.d/su
do work to launch softwares as root in the meantinepkexec
(which was meant to replacegksu
andgksudo
) get its issues together when everything else said here failed. -
Toby Speight over 3 years
xhost +si:localuser:root
would be a more targeted approach, better than allowing all users.