Greeter Screenshots blocked by required authorization

GraphicsMagick’s gm, ImageMagick’s import, xwd, and scrot all produce errors trying to produce a screenshot of the login greeter, in this case, KDM3, but I don’t believe the actual greeter running is relevant. No X sessions are running, just KDM3. I’m currently trying in TW, to attach to a bug report:

# magick import -screen :0 greeter.png
import: unable to open X server '' @ error/import.c/ImportImageCommand/348.
# import -screen :0 greeter.png
import: unable to open X server '' @ error/import.c/ImportImageCommand/348.
# magick import -display :0 greeter.png
Authorization required, but no authorization protocol specified

Authorization required, but no authorization protocol specified

import: unable to open X server ':0' @ error/import.c/ImportImageCommand/348.
# xwd -out screenshot.xwd -root -display :0.0 | xwdtopnm | pnmtopng > screenshot.png
Authorization required, but no authorization protocol specified

Authorization required, but no authorization protocol specified

xwd:  unable to open display ':0.0'
xwdtopnm: couldn't read XWD file header
pnmtopng: Error reading first byte of what is expected to be a Netpbm magic number.  Most often, this means your input file is empty
#

The forum software pops up “similar to” reports dating back 10 or more years having nothing to do with screenshots. Only thing resembling this I’ve been able to get Google to spit out is here, but that and everything it returns seems to be about getting results from a running X or Wayland session, not the greeter.

# xauth list
#

From remote:

# loginctl show-session $XDG_SESSION_ID
Id=6
User=0
Name=root
Timestamp=Mon 2025-06-09 12:50:59 EDT
TimestampMonotonic=9072961190
VTNr=0
TTY=pts/0
Remote=yes
RemoteHost=00srv.ij.net
Service=remote
Scope=session-6.scope
Leader=2941
Audit=6
Type=tty
Class=user-early
Active=yes
State=active
IdleHint=no
IdleSinceHint=1749487856432792
IdleSinceHintMonotonic=9069473614
CanIdle=yes
CanLock=yes
LockedHint=no

From console:

# loginctl show-session $XDG_SESSION_ID
Id=5
User=0
Name=root
Timestamp=Mon 2025-06-09 12:33:02 EDT
TimestampMonotonic=7995851490
VTNr=3
Seat=seat0
TTY=tty3
Remote=no
Service=login
Scope=session-5.scope
Leader=2882
Audit=5
Type=tty
Class=user-early
Active=yes
State=active
IdleHint=no
IdleSinceHint=1749487976000000
IdleSinceHintMonotonic=91890408022
CanIdle=yes
CanLock=yes
LockedHint=no

String ‘auth’ is nowhere to be found in import’s man page. Where can authorization come from? How can it be given to import? Do I need to feed it one of KDM’s PIDs somehow? Is this even possible without using a VM? Apparently I’ve asked before without getting a working answer. :frowning:

Sadly for you, I don’t think you’ll get a working answer. AFAIK no other users here use “Other” versions of the distros, nor KDE3. It is simply not supported. Going against that basically puts you on your own. I’ve installed other DE’s just for support reasons. but KDE3 will definitely not be one of them. Nor will I install EOL versions of whatever openSUSE. Doing so does not help anybody.

The software’s tagging system here doesn’t work for me. It doesn’t let me pick TW and Slowroll and Leap 16beta and Leap 15.6 in any way I can discern, and I don’t see any all of the above that works either.

This is an all of the above issue: TW, Slowroll, 16.0beta, 15.6. The results from the same attempts using LightDM instead of KDM3 produce the same error messages, e.g.:

# scrot -D :0 greeter.png
Authorization required, but no authorization protocol specified

Authorization required, but no authorization protocol specified

scrot: Can't open X display. It *is* running, yeah? [:0]
#

With the KDM3 login screen active, switch VT, login as root and run
ps -ef |grep kdm or ps aux | grep X
That should tell you how it runs, and hopefully provide you with a location of the authorization cookie eg /var/run/xauth/…

Then you should be able to do something like

export DISPLAY=:0
export XAUTHORITY=/var/run/kdm/<something>
import -display :0 screenshot.png

I was able to do this succesfully to capture my SDDM login screen image.

1 Like

It is rather amusing question from someone boasting about managing dozens of Linux installations.

It comes from the X11 server options which are provided by whatever program started X11 server. Usually it is display manager. What stops you from looking at the arguments of the running X11 server with ps command?

Thank you @deano_ferrari,

On Slowroll with LightDM:

# ps -ef |grep dm | grep cookie
# ps aux | grep X | grep cookie

Looking at the output without grepping cookie, I don’t recognize anything pointing to that magic cookie:

# ps -ef |grep tdm
root         977       1  0 15:23 ?        00:00:00 /usr/sbin/lightdm
root         990     977  0 15:23 tty7     00:00:00 /usr/bin/Xorg.bin :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
root        1038     977  0 15:23 ?        00:00:00 lightdm --session-child 17 20
lightdm     1051       1  0 15:23 ?        00:00:00 /usr/lib/systemd/systemd --user
lightdm     1053    1051  0 15:23 ?        00:00:00 (sd-pam)
lightdm     1060    1038  0 15:23 ?        00:00:00 /usr/sbin/lightdm-gtk-greeter
lightdm     1064    1051  0 15:23 ?        00:00:00 /usr/bin/dbus-broker-launch --scope user
lightdm     1065    1064  0 15:23 ?        00:00:00 dbus-broker --log 4 --controller 10 --machine-id 17d2bffebe9c46da883a025ce8f8204a --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
lightdm     1066    1051  0 15:23 ?        00:00:00 /usr/libexec/at-spi2/at-spi-bus-launcher
lightdm     1071    1066  0 15:23 ?        00:00:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user
lightdm     1072    1071  0 15:23 ?        00:00:00 dbus-broker --log 4 --controller 9 --machine-id 17d2bffebe9c46da883a025ce8f8204a --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000
root        1083     977  0 15:23 ?        00:00:00 lightdm --session-child 13 20
lightdm     1084    1051  0 15:23 ?        00:00:00 /usr/libexec/at-spi2/at-spi2-registryd --use-gnome-session
root        1469    1395  0 15:41 pts/0    00:00:00 grep --color=auto tdm
# ps aux | grep X
root         990  0.0  1.8 587396 70644 tty7     Ssl+ 15:23   0:00 /usr/bin/Xorg.bin :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
root        1473  0.0  0.1   6668  4272 pts/0    S+   15:42   0:00 grep --color=auto X
#

/var/run/ redirects/symlinks to /run/ now.

Really? And what about

1 Like

So, do

export DISPLAY=:0
export XAUTHORITY=/run/lightdm/root/:0

You’re making this hard.

1 Like

Thank you for your interest. I used ps before opening this thread, among other tools. I looked for /run/kde* too. I found nothing helpful, ancient posts from Google, nothing that pointed me to the magic for quite some time trying. This points to a solution with LightDM 12 years ago that worked to produce the entire 17M two screen area rather than its <20% of screen width greeter window:

# sleep 5; DISPLAY=:0 XAUTHORITY=/run/lightdm/root/:0 xwd -root > lightdm.xwd

Not exactly what I wanted, but headway for LightDM at least.

My eyes are considerably older than yours I strongly suspect. And, as to the magic, I was looking for something that looks like .Xauthority, .ICEauthority or something else cryptic.

My inability to work with symbolism is what lead me away from programming about 51 years ago in college. It hasn’t gotten any better that I can tell since. I learn via examples or experiments, not example-free man pages, and not nearly as well as I used to either.

With KDM, there is nothing equivalent to /run/lightdm/root/:0. :0 only shows up as:

# ls -gGh /run/xdmctl/
total 0
drwxr-xr-x 2 60 Jun  9 16:48 dmctl
drwxr-xr-x 2 60 Jun  9 16:48 dmctl-:0
prw--w---- 1  0 Jun  9 16:48 xdmctl
prw--w---- 1  0 Jun  9 16:48 xdmctl-:0
#

Each of the dirs contains merely socket. KDM is represented in /run/ only by kdm3.pid.

# ps -ef | grep dm
root        1009       1  0 16:47 ?        00:00:00 /usr/sbin/mdadm --monitor -d 60 -m root@localhost --scan -c /etc/mdadm.conf
root        1575       1  0 16:48 ?        00:00:00 /opt/kde3/bin/kdm
root        1583    1575  0 16:48 tty7     00:00:03 /usr/bin/Xorg.bin -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-Yo5kRv
root        1599    1598  0 16:48 ?        00:00:01 /opt/kde3/bin/kdm_greet
root        1887    1643  0 17:15 pts/0    00:00:00 grep --color=auto dm
# export DISPLAY=:0
# export XAUTHORITY=/var/lib/xdm/authdir/authfiles/A:0-Yo5kRv
# import -display :0 kdm3greeter.png
^C

I waited several minutes, then visited vt7, and found a partially painted screen. I shut down, disconnected the larger display, then booted and tried again, with only 1680x1050, visiting vt7 sooner, but it didn’t help. Import seems to be hung. The bug I want the screenshot for is about image handling, so I suppose recursivity could be involved.

With env unchanged, I tried, in order:

  1. scrot -D ‘:0’ greeter.png
  2. sleep 5 ; scrot -D ‘:0’ greeter.png
  3. sleep 30 ; scrot -D ‘:0’ greeter.png
  4. sleep 15 ; scrot -D ‘:0’ -a 554,340,572,372 greeter.png

#1 got me a 5k image of 100% black, after I forgot to visit vt7 for some seconds. #2 did the same thing except 49k after a quick switch to vt7. #3 got the whole screen in 49k. After several more tries, #4 got me what I wanted in 23k for the bug report. :slight_smile: I customized kdmrc to omit all users but root for the upload image . :wink:

Ignoring the extraneous commentary in this thread, you now know how to get the required authorization. Good. (Your opening post could have been one or two sentences asking for help with the above.)

Import works - you just needed to switch back to the DM, login your session and view the image created from there. :wink:

1 Like

You’ve marked this as “Solution”. IMSHO opinion it is not, it’s just another workaround

Workaround for what?

A workaround is a temporary or alternative approach used to bypass a problem or limitation, while a solution is a complete and permanent fix for an issue. Workarounds are often used when a better solution isn’t immediately available or feasible.

Solution would be to stop using outdated distro versions and ditto software.

I know very well the meaning of a workaround. What I don’t understand is what it is that you say a workaround was found for here? I was shown a way to find the key, the authorization, to unblock, just as the subject defines.

I write here from Leap 15.6, running 24/7, and software and a DE that don’t require relearning everything with every release, and break workflows in between. Others I write about run here only as required to do what needs doing that requires using other hardware and/or operating systems, regardless of their ages, and can’t be done with VMs.