Linux display no protocol specified

How to resolve ‘No protocol specified’ for su user

I am trying to use an alternate user (non-admin) to execute graphical software on my system. This alternate user has been named and given a UID and GID to match a remote system user of the same name. The UID is 500 so I believe that makes the user a ‘non-login’ user. Starting from Ubuntu logged into my main account, I open a terminal and su to the alternate user. I then attempt to execute the command to start the application and receive ‘No protocol specified’. Is this because of the UID

10 Answers 10

In my case the new display server protocol wayland was the problem,

just do xhost + local: then other users (e.g. root) are allowed to run programs in your session, network connections however will not be allowed.

If you want to allow clients from any host, you can use xhost + without specifying any host at all. This is however unsafe, it would be better to just specify the host(s) for which you want to grant access to your session.

@danger89 while this does work it allows any host to connect to your session if you have no firewall rules to prevent remote access (Not every distribution has firewall rules which deny all incoming requests e.g. ubuntu does not have preconfigured rules to prevent access to servers like samba or apache which the user might want to install) so for new linux users this could become a problem. Personally I would limit the access just to be on the save side

This worked for me. but the problem is, I already ran the program before as su. Why, all of a sudden it stopped working without this inconvenience?

@MADforFUNandHappy however, that host would first have to connect via SSH or some similar means, i.e. it would still have to know the system password to use X services, right

The problem is not occurring because of the UID of the user. 500 is just fine as a UID, and that UID doesn’t make it a ‘non-login’ user except in the eyes of the default settings of some few display managers.

The error message No protocol specified sounds like an application-specific error message, and an unhelpful one at that, but I am going to guess that the error is that the application is unable to contact your X11 display because it does not have permission to do so because it’s running as a different user. Applications need a «magic cookie» (secret token) in order to talk to the X11 server so that other processes on the system running under other users cannot intrude on your display, create windows, and snoop your keystrokes. The other system user does not have access to this magic cookie because the permissions are set so that it is only accessible to the user who started the desktop environment (which is as it should be).

Читайте также:  Система линукс не загружается

Try this, running as your original user, to copy the X11 cookie to the other account:

su - -c "unset XAUTHORITY; xauth add $(xauth list)" 

then run your application. You may also need to unset XAUTHORITY in that shell too. That command extracts the magic cookie ( xauth list ) from your main user and adds it ( xauth add ) to where the other user can get it.

Bizarrely, using your quoted command gives ‘su: must be run from a terminal’. But it is in a terminal.

@JCollins oops, yeah, that would be a problem if su wants to ask for a password. Try this new command.

@Celada, gold, worked a treat. Could you have a go at detailing what that command is doing and how? And maybe explaining why the original incarnation did not?

@JCollins you’ll have to redo it each time after you log out and log in because a brand new magic cookie gets generated each time. That’s normal, it’s part of the security model.

Suppose you want to brute force get yourself a connection with X.

Lets assume you are already running your commands on the server (where X runs), otherwise get that to work first and then use ‘ssh -X user@server’ from the client afterwards ;).

There might be several ways to run the xauth commands, for example, you might be using ‘sudo’, but that might lose or change environment variables. The following environment variables need to be preserved: DISPLAY and XAUTHORITY. To test if that is the case you could run ‘echo $XAUTHORITY’ in the same way you run your commands, but make sure you aren’t expanding the environment variables before you run those commands. For example, try: sudo bash -c ‘echo «$XAUTHORITY»‘ to see what XAUTHORITY really is after you run your sudo (if it disappears you might need to add something to your sudoers file, see elsewhere).

Eventually, run the following command as the user that you want to get access with, on the server:

This will show the ‘Authority file’ that will be used (/root/.Xauthority by default, for root, or something like /home/theuser/.Xauthority). If it shows the correct .Xauthority file then you don’t have to worry about the XAUTHORITY environment variable actually (actually, I wouldn’t know when it wouldn’t, except if you want to manipulate a non-standard place of that file).

Remove that file (if it even exists):

mv /root/.Xauthority /root/.Xauthority.bak

In the above command, replace /root/.Xauthority with the correct XAUTHORITY file for your case of course.

Recreate it, but empty (this is needed for a lot of commands):

At this point you’ll get the No protocol specified error, even if you got Invalid MIT-MAGIC-COOKIE-1 before. Find the authority file that the X server is using at the moment:

This should show something like:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/ -background none -noreset -displayfd 17 vt7

Читайте также:  Linux variables with spaces

The file name after -auth is what you need in the next command. Run this as root:

That lists a 32 digit hexadecimal key. For example the output could be:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Use that to generate your .Xauthority file (as user who needs to login again):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

replace ‘c0eaf749aa252101a0f57d5087089db7’ with what was returned by the list command for you. Now your .Xauthority should be size 51 bytes and you can connect to the X server (again).

PS If you start Xorg by running /usr/bin/startx , like me; then you might see something like:

root 1652 0.0 0.0 12788 5792 ? Ss jan20 0:00 login -- carlo carlo 1834 0.0 0.0 8140 3468 tty1 Ss jan20 0:00 \_ -bash carlo 1887 0.0 0.0 7404 3236 tty1 S+ jan20 0:00 \_ /bin/sh /usr/bin/startx carlo 1905 0.0 0.0 3912 828 tty1 S+ jan20 0:00 \_ xinit /home/carlo/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.WWPpq4OSlA root 1906 1.2 0.7 25576848 235104 tty1 Sl jan20 207:56 \_ /usr/lib/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.WWPpq4OSlA carlo 1917 0.0 0.0 143408 10884 tty1 Sl jan20 0:00 \_ startplasma-x11 

And the /tmp/serverauth.WWPpq4OSlA was deleted. See /usr/bin/startx script for how this works:

mcookie=`/usr/bin/mcookie` xserverauthfile=`mktemp -p /tmp serverauth.XXXXXXXXXX` trap "rm -f '$xserverauthfile'" HUP INT QUIT ILL TRAP KILL BUS TERM xauth -q -f "$xserverauthfile"  

adding the random cookie to the users .Xauthority file.

In this case the cookie has completely vanished thus. The only place where you can get it back from is the memory (RAM) of the Xorg process; but I am too lazy to figure out how to recover that. Just restarting X should regenerate your .Xauthority file with a new cookie and also restart the server with that same cookie, of course.

Источник

Arch Linux

When running pavucontrol (without sudo I mean as a regular user) I get the following error.

[ka@archlinux ~]$ pavucontrol No protocol specified Unable to init server: Could not connect: Connection refused (pavucontrol:2751): Gtk-WARNING **: 21:53:02.704: cannot open display: :0

Even when I run scrot, the following error shows.

[ka@archlinux ~]$ scrot No protocol specified Can't open X display. It *is* running, yeah? [:0]

But when I start awesome with xorg-xinit this error doesn't shows up. As I want to use Lightdm , thus I need a solution.

Last edited by kawsar (2020-10-09 09:27:16)

#2 2020-10-09 03:49:50

Re: [Solved]No protocol specified error when running gui app from terminal

looks like your DISPLAY environment variable wasn't setup for your X terminal emulator. how about this command?

#3 2020-10-09 05:38:45

Re: [Solved]No protocol specified error when running gui app from terminal

Last edited by kawsar (2020-10-09 05:47:33)

#4 2020-10-09 06:00:00

Re: [Solved]No protocol specified error when running gui app from terminal

Pls output this command from your X terminal emulator:

# pacman -S pstree $ pstree -uT 

#5 2020-10-09 06:04:57

Re: [Solved]No protocol specified error when running gui app from terminal

Pls output this command from your X terminal emulator:

# pacman -S pstree $ pstree -uT 

It seems pstree package doesn't exist.

#6 2020-10-09 06:06:43

Re: [Solved]No protocol specified error when running gui app from terminal

The client tries to access :0

(pavucontrol:2751): Gtk-WARNING **: 21:53:02.704: cannot open display: :0
Unable to init server: Could not connect: Connection refused

Check the $XAUTHORITY environment as well as ~/.Xauthority
Possibly also a problem w/ the hostname (output of "hostnamectl"?)

Last edited by seth (2020-10-09 06:08:12)

#7 2020-10-09 06:10:20

Re: [Solved]No protocol specified error when running gui app from terminal

It seems pstree package doesn't exist.

Sorry, should be psmisc package.

#8 2020-10-09 06:24:12

Re: [Solved]No protocol specified error when running gui app from terminal

The client tries to access :0

(pavucontrol:2751): Gtk-WARNING **: 21:53:02.704: cannot open display: :0
Unable to init server: Could not connect: Connection refused

Check the $XAUTHORITY environment as well as ~/.Xauthority
Possibly also a problem w/ the hostname (output of "hostnamectl"?)

Edit: pstree is in psmisc

export XDG_RUNTIME_DIR=/run/user/1000 export XAUTHORITY="XDG_RUNTIME_DIR"/Xauthority

and this line in my /etc/lightdm/lightdm.conf

user-authority-in-system-dir=true
[ka@archlinux ~]$ hostnamectl Static hostname: archlinux Icon name: computer-desktop Chassis: desktop Machine ID: be3055d227fb46a094ca1c2ca41374cd Boot ID: 937964e08cd24a73b4a1314953b52232 Operating System: Arch Linux Kernel: Linux 5.4.69-1-lts Architecture: x86-64
[ka@archlinux ~]$ pstree -uT systemd─┬─NetworkManager ├─accounts-daemon ├─alacritty(ka)───zsh───nvim───node ├─alacritty(ka)───zsh───pstree ├─dbus-daemon(dbus) ├─lightdm─┬─Xorg │ └─lightdm───awesome(ka) ├─lvmetad ├─polkitd(polkitd) ├─rtkit-daemon(rtkit) ├─systemd(ka)─┬─(sd-pam) │ ├─at-spi-bus-laun │ ├─dbus-daemon │ ├─gvfsd │ ├─gvfsd-fuse │ └─pulseaudio───gsettings-helpe ├─systemd-journal ├─systemd-logind ├─systemd-timesyn(systemd-timesync) ├─systemd-udevd ├─upowerd └─zsh(ka)───MainThread─┬─Privileged Cont ├─8*[Web Content] └─WebExtensions

Last edited by kawsar (2020-10-09 06:35:34)

Источник

Arch Linux

I've spent part of last night and most of today working on this problem.

So, I have a laptop with an external VGA port. For the sake of argument, let's say I'm trying to extend my desktop onto another monitor. I run 'xrandr' and get the following.

Okay. The display isn't set to the $DISPLAY variable when the X server starts. 'ps aux | grep X' shows that /usr/bin/Xorg is running on :0. 'export DISPLAY=:0' takes care of this. Let's run xrandr again.

No protocol specified Can't open display :0

Now I'm stuck. So googling around, I read something about using xhost + to fix this. So I run 'xhost +'. Same error.

No protocol specified xhost: Can't open display :0

Now, here's the real stumper. I'm going to stop GDM and run startx. Now, GDM uses the /usr/bin/Xorg binary to run the X server. When I run startx, the X server is using the /usr/bin/X binary, also on :0. Except when I do this, the $DISPLAY variable is automatically set for me and both xrandr and xhost don't give me this "Can't open display" error.

Help? If you need to see a debug log or config file, just ask.

#2 2011-07-23 10:33:55

Re: xhost/xrandr "No protocol specified, cannot open display :0"

Where do you run the xrandr command from? From a tty, or a terminal from within the running X application?

This usually indicates a permission problem; so it would be interesting to know as which user you are logged in, and as which user you are executing the xrandr command that results in this error.

Now, GDM uses the /usr/bin/Xorg binary to run the X server. When I run startx, the X server is using the /usr/bin/X binary, also on :0. Except when I do this, the $DISPLAY variable is automatically set for me and both xrandr and xhost don't give me this "Can't open display" error.

This seems highly unlikely to be related, /usr/bin/X is simply a symlink to Xorg, so it runs the exact same program

Источник

Оцените статью
Adblock
detector