Siduction Forum
Siduction Forum => Software - Support => Topic started by: Mte90 on 2024/01/22, 11:02:00
-
I want to able to run from console applications as root to simplify various things.
Right now with kde and GTK software I get that error:
mte90 / home mte90 partitionmanager
Invalid MIT-MAGIC-COOKIE-1 key
qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Annullato (core dump creato)
mte90 / home mte90 134 gprename
Invalid MIT-MAGIC-COOKIE-1 key
(gprename:30324): Gtk-WARNING **: 10:59:23.341: cannot open display: :0
I know that is not something safe but I know what I do in those cases.
Can you help me on fixing those errors?
I still using xorg right now.
-
For graphical applications use pkexec to avoid errors.
pkexec application-name
You will be prompt for your password.
-
Nope, I am getting the same error as non-root when I try it:
mte90 Desktop pkexec dolphin
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Annullato (core dump creato)
-
Did you try
su-to-root -X -c <application-name>or If error messages related to dbus occur, expand the input:
su-to-root -X -c 'dbus-launch <application-name>?
Also take a look at the manual '7.1.1 Work as root'.
I use XFCE. Maybe the behavior is different in KDE.
-
I was searching you error and it seems to only come up while logged in via ssh remotely. Is this the case in your situation?
-
Thanks both,
so no I am trying root on my workstation with siducation not on SSH.
I tried "su-to-root -X -c 'dolphin'" as non-root user, opens a terminal to write the password, so for sure it is a workaround (I will add a new alias), but it will be handy to be able to launch GUI applications from the root user to avoid to write the password again.
-
Strange, really strange, I am able to open dolphin as root, strange (I su - into root), don't know what I have done that this works. 8)
root@localhost:~# dolphin
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
I rebooted several times, logged -out and -in, it works, here™, no joke!
I thought it was disabled long time ago because of safety reasons, there was a big discussion on that.
root@localhost:~# LANG=C partitionmanager
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kf.coreaddons: "Could not find plugin kpmcore/"
Could not create instance of plugin ""
Loaded backend plugin: "pmsfdiskbackendplugin"
QWidget::setMinimumSize: (MessageWidgetDock/QDockWidget) Negative sizes (0,-1) are not possible
QWidget::setMaximumSize: (MessageWidgetDock/QDockWidget) Negative sizes (0,-1) are not possible
"Using backend plugin: pmsfdiskbackendplugin (1)"
"Scanning devices..."
"Device found: CT250MX500SSD1"
230399 139024 4096
unknown file system type "" on "/dev/sda3"
14710672 4987186 4096
208127 54186 4096
5245439 2068991 4096
"Partition ‘/dev/sda4’ is not properly aligned (last sector: 120.407.174, modulo: 1.159)."
"Partition ‘/dev/sda5’ is not properly aligned (last sector: 391.761.088, modulo: 1.217)."
"Scan finished."
Works too!
-
I have this machine rolling since 2012 as I can remember so maybe something was messed up...
Maybe it is enough to set somewhere what is the display to use looking at the error I get.
-
I have this machine rolling since 2012 as I can remember so maybe something was messed up...
Maybe it is enough to set somewhere what is the display to use looking at the error I get.
Your system behaves as it should, nothing wrong!
My™ system behaves strange, that what I am trying to say.
su-to-root I would recommend too, what also works is "doas" (should), see our manual.
https://manual.siduction.org/sys-admin-doas_en.html
On the other hand you can try another file manger like krusader or doublecmd and so on
-
Tested now doas following the wiki and works too.
I only sad that as root user I am not able to run any GUI , maybe it is something to configure on xorg or a environment variable?
-
Tested now doas following the wiki and works too.
I only sad that as root user I am not able to run any GUI , maybe it is something to configure on xorg or a environment variable?
I am not on Siduction at the moment, but will look it up later on. The problem could/should be, that you do not have the "Xauthority" "MIT-MAGIC-COOKIE" to access the user's X-Display. You must provide that (temporary and local) cookie for the root-user, too.
Normally, even with Siduction, this is handled automatically, when you open a terminal (within X11!) as user and then su/sudo/doas from there.
The cookie used to be in a user's homedirectory in an .xauth- (or was it .Xauth-?) file, Ubuntu does it via gdm in /run/user/"userid"/gdm/Xauthority and I guess, KDE-Siduction will do it in a similar sddm-file, but as written, I have to look this up, later, sorry.
-
I have the file /home/mte90/.Xauthority maybe it's enough to do a symlynk in the /root/ folder to access the xorg environment?
-
I have the file /home/mte90/.Xauthority maybe it's enough to do a symlynk in the /root/ folder to access the xorg environment?
You may try, it should not do any harm. But since I do not know, when .Xauthority gets removed or if it will just be replaced at next login,
you may experience a "dangling symlink" sometimes eventually.
-
Uhm on the root user I see the same file that is a symlink:
lrwxrwxrwx - - root root 13 lug 2020 .Xauthority -> /var/run/xauth/*
That doesn't exists, this can explain a bit what is happening.
So now:
lrwxrwxrwx - - root root 23 gen 17:38 .Xauthority -> /home/mte90/.Xauthority
But I am getting the same error, maybe I need to reboot to test it.
-
As promised, now on Siduction, I can report my situation there (with working "root"-X11-programs). It is the display-manager, which creates the "master"-authfile in /run/sddm/ (sddm is the display-manager for KDE-siduction). "root" automatically gets "copies" of it - several in my case - in its home as .xauth... with ... being uniqe endings. I assume, that the terminal(s) (automatically) generate them, when doing su/sudo/doas. It also seems important, that only the corresponding user has access to them (rw-------).
In my case, there is no .Xauthority file in root's home (/root).
-
In the meantime I reboot and tried from root now that there is the symlink and I am getting the usual error, maybe the file needs to be symlinked to a different one?
Someone has ideas on how to get a useful log?
-
Uhm on the root user I see the same file that is a symlink:
lrwxrwxrwx - - root root 13 lug 2020 .Xauthority -> /var/run/xauth/*
I have reflected a little bit over that strange entry, and do think, I now do understand its meaning. I am not sure, the construction is valid, because I have never seen a symlink with a wildcard, yet, i.e. pointing to several files.
As I reported previously, "root" gets/can get several .xauth... files simultaneously, although with the same content (MIT-COOKIE). Now, ".Xauthority -> /var/run/xauth/*" could try to make .Xauthority point to all files in /var/run/xauth. As written, I do not know, if this is a valid construct. Anyways, at least one file has to appear in /var/run/xauth. So you should first check, (from) where your(!) xauth-files are generated, when they do not appear under (/var)/run/xauth [the var is unnecessary after the last filesystem rework (some very bad moves, in my opinion)].
You can check, where "your" xauth-files appear with (e.g.) "ps -aef | fgrep X". It will show you the X "session" command and the path to the "xauth"s. Then you might recreate the .Xauthority symlink to that path, including the "*".
In my view this should give you a ticket to access the X-Display.
As written before, I see it vital, that the target file (not the symlink!) may be read by its user, only.
Edit: regarding the logs, you can have a view at /var/log/Xorg.log.n for the X11 setup, but I doubt, you find something useful for your case, there. Then you can have a look into the .xerrors file in the respective users home(s). Finally I would have a look at /var/log/syslog, but with systemd this may no longer exist, so someone else has to tell you, how to achieve this with "journalctl" [also a step back, to have a binary file as a logfile, in my opinion - how do you look it up from a "live" system?].
-
https://wiki.archlinux.org/title/Running_GUI_applications_as_root#Circumvent_running_graphical_applications_as_root
Maybe you find something useful, but read the warning!
What does "xauth list" telling?
Something like that?
:~$ xauth list
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 40cc267484a15405a088d742897e6611
#ffff##:0 MIT-MAGIC-COOKIE-1 40cc267484a15405a088d742897e6611
-
A few additions:
- Under KDE/Plasma (X11) you can find xauth_xxxxxx under /run/sddm/, for example /run/sddm/xauth_sOZLbM
- .Xauthority is only necessary if the environment variable XAUTHORITY is not defined.
env |grep XAUTH
XAUTHORITY=/tmp/xauth_VlcQly
man xauth
https://www.ibm.com/docs/en/aix/7.3?topic=x-xauth-command (https://www.ibm.com/docs/en/aix/7.3?topic=x-xauth-command)
edlin
-
mte90 / tmp ps -aef | fgrep X
root 1426 1384 3 10:37 tty2 00:07:22 /usr/lib/xorg/Xorg -dpi 0 -background none -seat seat0 vt2 -auth /run/sddm/xauth_ciVfgQ -noreset -displayfd 16
mte90 58985 41226 0 14:34 pts/3 00:00:00 grep -F X
Root user doesn't have .xsession-errors file but mine user yes but is just a list of environment variables.
mte90 / tmp xauth list
KITT/unix:0 MIT-MAGIC-COOKIE-1 01561c29aaed3bd33c6f6e42b8b8984c
#ffff##:0 MIT-MAGIC-COOKIE-1 01561c29aaed3bd33c6f6e42b8b8984c
as root:
xauth list
KITT/unix:1 MIT-MAGIC-COOKIE-1 b47b2bb365dc1e8a455f10a0c721817c
kitt/unix:0 MIT-MAGIC-COOKIE-1 29b63642b81aa11e96b40bbfcabd6bbb
KITT/unix:0 MIT-MAGIC-COOKIE-1 75a81ff9835158d2140749d24e7bcd66
mte90 / tmp env |grep XAUTH
XAUTHORITY=/tmp/xauth_eHJBEs
Seems that I had this in my root bashrc:
env |grep XAUTH
XAUTHORITY=/home/mte90/.Xauthority
Removed and now the root user is able to run GUIs.