I want to debug something graphics-related on a remote machine where I am logged in via ssh. When I try to run DISPLAY=:0 xrandr, I get the following error message:
Authorization required, but no authorization protocol specified
Can't open display :0
I can get text output from mpv with DISPLAY=:0 mpv, but when I try to play a movie, I get the same error. I can use sudo in the ssh session. A ~/.Xauthority file exists. This is what 99% of discussions for this issue on Google are about. How can I make the error go away and run xrandr to see the display configuration of the remote machine?
Answering here because I came across this when trying to solve the same problem.
I have lightdm running, the solution for me so far was:
export XAUTHORITY=/run/lightdm/root/:0
before running xrandr. However I needed to do that while being root (there’s probably a way to avoid that but since I’m just doing this to debug what’s happening, I didn’t really look deeper)
Thanks, that’s great! That’s very helpful in the future when I need to find the Xauthority.
I tend to think that answering old threads is never wasted since they’re often indexed in google. I came across this thread when I had the same problem as OP
Is there a way to find what is the currently used display? I’ve noticed that after logging in through lightdm, wayland plasma uses :1 for example
everything works. Output of echo $(/home/erik/bin/xa.sh) DISPLAY=:0 mpv /path/to/movie/file.mkv is identical to the command above, so why can’t bash find the xauthority file? Prepending sudo to xa.sh doesn’t help either.
Permission to the xauthority file and it’s parent dir are restricted to my user and my group, but that shouldn’t matter since the access works fine if I just write the path out.
Hey, thanks for coming back on this after such a long time! Such things are interesting, right?
I gave it a quick spin (without the added head -c -1). If you just use $(xa.sh), bash will try to find and execute a command called XAUTHOITY=…. And fail.
But you could of course declare a variable and continue, like:
Works nicely here when started from tty2 (Ctrl+Alt+F2) as my user. Will of course only start the video when tty7 display :0 is active, i.e. you switch back using Ctrl+Alt+F7. mpv commands like q to quit can be used from bothtty2 and tty7.
Note 1: When starting as root (probably shouldn’t), you might not get video and/or audio with mpv, depending on system configuration.
Note 2: The script is of course a rather “brute force” approach, going through the user’s process list, trying to read the process’ environment and blindly accepting the first XAUTHORITY= found isn’t really very elegant. But well, it helped me sometimes…
I removed the line with head -c -1 as well since that was a remnant of my tries to get it work somehow, but it’s not needed, you are correct.
But the connection via ssh is crucial for the issue to surface. Maybe something to do with different access rights (locally, you can use reboot, remote, it needs to be sudo reboot), but it’s quite difficult and time-consuming to find a fix in this topic.
My declare $(/home/emk2203/bin/xa.sh) && DISPLAY=:0 mpv /path/to/movie/file.mkv gives no initial bash error, but still fails. mpv gives the error of Invalid MIT-MAGIC-COOKIE-1 key (and no video) as if the declare statement didn’t happen.
Changing declare to export works, though. The issue is finally solved, and I can continue to use my HTPC via ssh and don’t have to lift my a$$ from the couch everytime…
I was thinking about export but didn’t want to export unnecessary stuff, since it seemed to work (on the virtual console). Should have tried with a real ssh, my bad.
So for all others that might find this useful: Use export instead of declare:
Makes me happy to see what useful solutions come from working together. Great it works for you (us)—didn’t expect something I did years ago in the expectation of only needing it once would still be useful. Good I saved it into my ever-increasing ~/bin folder back then…
Long time since… In olden times we didn’t have to think about all that authorization stuff—we could simply run things like xsnow or xpenguins on a colleague’s terminal, to everyone’s delight. People were less malicious in those days.
I guess that looking through all user’s processes came from not having something global, and of course each process has its own environment. Like open a bash within a DE (env | wc -l gives me 56 items) or in a virtual terminal tty2 (env | wc -l gives me 35 items and of course no XAUTHORITY). Same user, two bashes, maybe even the same .profile and .bashrc, but still completely different environments.
To avoid permission issues I only check processes of “this” user (and of course still get many, that’s why they’re sent to the bit bucket).
My first naive assumption back all these years was “I am the user, I am logged in, so there should be something telling me the XAUTHORITY!” Boy, was I wrong… X being much older than its security system, which came much later as an afterthought, doesn’t always make things easy. But it can still do things Wayland cannot (yet). That’s one of the reasons I decided to stick with it, for now. (Using EOS/Cinnamon on X11.)
EDIT: Oh, you took your question away! [Why do I check all processes and not just env?]
The reason I took it away was that I found out that there’s no XAUTHORITY when using env via ssh, confirming what you just wrote. So the question made no sense.
Confirms that your script is really needed, no shortcuts possible.