Starting Nextcloud Sync Client via shell script results in Xhost / Xauthority error

Support KDE Plasma
1

The task I have to solve is the following: “how to automatically start nextcloud sync client (appimage GUI application) without unlocking (Manjaro KDE 24) desktop after boot?”.

To chop the task down, I first tried to start a regular GUI application via a shell script.

I installed these dependencies:

sudo pacman -S xorg-xeyes xorg-xhost

The script ~/xeyes.sh looks like this:

#!/bin/bash

set -euo pipefail
set -x

export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
export DISPLAY=:0
export XAUTHORITY=/home/$USER/.Xauthority

/usr/bin/xhost +SI:localuser:$USER:

xeyes

When I start the shell script bash ~/xeyes.sh, this error is printed to the terminal (failing at line /usr/bin/xhost +SI:localuser:$USER:):

Authorization required, but no authorization protocol specified
/usr/bin/xhost:  unable to open display ":0"

I also tried already fiddling around with various /usr/bin/xauth flags etc (provided by perplexity.ai, chatgpt, … referring to Manjaro Forum links and stackoverflow etc), and also tried using /usr/bin/xhost +local: instead of the above mentioned command, always the same result.
When I run the xhost command (either /usr/bin/xhost +SI:localuser:$USER: or /usr/bin/xhost +local:) natively in the terminal and then call the ~/xeyes.sh script, it starts properly the xeyes application.

My conclusion is that the shell script is not allowed to get access to X11 server, (which is indicated by failing xauth and xhost commands when being called in the script instead of natively in the terminal).
I want to start a GUI application (Nextcloud Sync Client AppImage) automatically on system boot without unlocking the desktop (means without the need of any user interaction, and without configuring the user auto-login feature that may introduce a security vulnerability).

My test system is as follows (QEMU-KVM virtual machine):

# uname -a
Linux discovery-encryption 6.10.13-3-MANJARO #1 SMP PREEMPT_DYNAMIC Tue Oct  8 03:24:49 UTC 2024 x86_64 GNU/Linux

# cat /etc/lsb-release
DISTRIB_ID="ManjaroLinux"
DISTRIB_RELEASE="24.1.1"
DISTRIB_CODENAME="Xahea"
DISTRIB_DESCRIPTION="Manjaro Linux"

# echo $XDG_CURRENT_DESKTOP
KDE

# echo $XDG_SESSION_TYPE
x11

# lspci | grep -i vga
00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 05)

# xauth list
discovery-encryption/unix:0  MIT-MAGIC-COOKIE-1  6b1d37afa714b4911ffee46c9024c600
#ffff##:0  MIT-MAGIC-COOKIE-1  6b1d37afa714b4911ffee46c9024c600

# printenv
COLORFGBG=15;0
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
DESKTOP_SESSION=plasma
DISPLAY=:0
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/dev/.gtkrc-2.0:/home/dev/.config/gtkrc-2.0
GTK_MODULES=canberra-gtk-module
GTK_RC_FILES=/etc/gtk/gtkrc:/home/dev/.gtkrc:/home/dev/.config/gtkrc
HOME=/home/dev
ICEAUTHORITY=/run/user/1000/iceauth_GrJnZK
INVOCATION_ID=cb4d53058df64494aa334cbc0a5248bf
JOURNAL_STREAM=9:6119
KDE_APPLICATIONS_AS_SCOPE=1
KDE_FULL_SESSION=true
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=6
KONSOLE_DBUS_SERVICE=:1.56
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_VERSION=240801
LANG=en_US.UTF-8
LANGUAGE=
LC_ADDRESS=de_AT.UTF-8
LC_IDENTIFICATION=de_AT.UTF-8
LC_MEASUREMENT=de_AT.UTF-8
LC_MONETARY=de_AT.UTF-8
LC_NAME=de_AT.UTF-8
LC_NUMERIC=de_AT.UTF-8
LC_PAPER=de_AT.UTF-8
LC_TELEPHONE=de_AT.UTF-8
LC_TIME=de_AT.UTF-8
LOGNAME=dev
MAIL=/var/spool/mail/dev
MANAGERPID=723
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/background.slice/plasma-kglobalaccel.service/memory.pressure
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
MOTD_SHOWN=pam
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
PATH=/home/dev/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
PROFILEHOME=
PWD=/home/dev
QT_AUTO_SCREEN_SCALE_FACTOR=0
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
SESSION_MANAGER=local/discovery-encryption:@/tmp/.ICE-unix/830,unix/discovery-encryption:/tmp/.ICE-unix/830
SHELL=/bin/bash
SHELL_SESSION_ID=48eeac8da1b3468b9954bc1e9ba0ec0a
SYSTEMD_EXEC_PID=768
TERM=xterm-256color
USER=dev
WINDOWID=4194328
XAUTHORITY=/tmp/xauth_oTAwQl
XDG_CONFIG_DIRS=/home/dev/.config/kdedefaults:/etc/xdg:/usr/share/manjaro-kde-settings/xdg
XDG_CURRENT_DESKTOP=KDE
XDG_MENU_PREFIX=plasma-
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=x11
XDG_VTNR=2
SHLVL=1
OLDPWD=/home/dev
LESS_TERMCAP_mb=
LESS_TERMCAP_md=
LESS_TERMCAP_me=
LESS_TERMCAP_se=
LESS_TERMCAP_so=
LESS_TERMCAP_ue=
LESS_TERMCAP_us=
LESS=-R
LS_OPTIONS=--color=auto
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:
P9K_SSH=0
_P9K_SSH_TTY=/dev/pts/1
P9K_TTY=old
_P9K_TTY=/dev/pts/1
_=/usr/bin/printenv

I kindly ask for further assistance here, I do not know to much internal details on how X11 handles authorization, nor how KDE is configured on behalf of that.

What steps are needed to make the above script just work (on a plain newly opened terminal, without any further configuration of .bashrc, .zshrc, etc or running any commands before calling the script)?
What would then be the easiest and most robust approach to run a GUI application automatically via a shell script on system startup without the need to log in (my first thought was systemd, because as far as I understood the user’s autostart scripts dir needs a successful login to the desktop environment)?

Many thanks for help in advance.

2

try changing your call to xhost to just:
xhost +
Less secure, but if it works at least it will give you some clues as to where to play around.

4

Thanks for the hint, unfortunately still the same output:

 # bash ~/xeyes.sh
+ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
+ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
+ export DISPLAY=:0
+ DISPLAY=:0
+ export XAUTHORITY=/home/dev/.Xauthority
+ XAUTHORITY=/home/dev/.Xauthority
+ /usr/bin/xhost +
Authorization required, but no authorization protocol specified

/usr/bin/xhost:  unable to open display ":0"
5

I don’t use nextcloud and I also don’t really understand trying to run a GUI application when no-one is logged in.

If you are trying to force nextcloud to sync have you looked at nextcloudcmd to see if you can just run that on a timer to sync without a GUI? nextcloudcmd is part of the nextcloud-client package.

https://docs.nextcloud.com/desktop/latest/advancedusage.html#nextcloud-command-line-client

1 Like
6

I had a similar problem and i suspect the problem is you have a root service trying to run an app in a user session. The correct user and display have to be specified. If you are not logged in at all, there is no user session.

I’ll see later how it worked out in my case but it was a root script running after the user is logged in.

1 Like
7

Check that your display is actually :0. I had problems with this a while ago when sddm decided to start my session on a different TTY to the one it had always used. This caused the actual display variable to be :1.

8

Mhm, I’ll try your suggestion. Thanks for the hint. Circumventing all the GUI stuff is probably the simplest solution (kinda embarrassing that I did not check the Nextcloud Docs properly).

1 Like
9

Here is my script/service, running as root and displaying message in a logged in user session. For some inspiration about dbus, display, etc. But you have to test how the whole will work without a logged in user. I guess ssdm has also its id and user and display, you just have to figure out the values.

10

I’ll check that as well, thanks for the inspirations! nextcloudcmd works and can be used properly via cron / systemd. But using the GUI app would be more convenient (in case of user interaction with the desktop pc).

On my Manjaro KDE desktop the xauthority files are stored in tmp, e.g. /tmp/xauth_VNbEEO, before the user is logging in, there is a xauth file owned by 964:964 and when the user logs in a new xauth file owned by 1000:1000 is created and the other one vanishes.

It appears to me that the desktop user cannot start an GUI application before logging in (because there is no xauth file for this user existing).
However using /usr/share/sddm/scripts/Xsetup at least xeyes did start before logging in, but it starts as root user, and running it via sudo -u <desktop_user> xeyes & (or similar) did not work either. Running /usr/bin/nextcloud (I replaced the appimage with sudo pacman -S nextcloud-client) as root also does not make much sense, because then it is not visible in the desktop UI at all (and it does not start properly anyways).

I’ll check how Ubuntu 24 behaves in this regard, and provide further info later (in case some more hints / ideas pop up).

11

According to less /etc/passwd, that user and group is git:

git:x:964:964:git daemon user:/:/usr/bin/git-shell

I’m not sure if it will be the same on your system, but my guess is that it probably is.

12

Good that you mention that, kinda my fault again. I tend to use ls -ahln ... by default, and the -n flag does this -n, --numeric-uid-gid like -l, but list numeric user and group IDs. This is why I assumed that 964 is just some arbitrary temporary ID. But as it seems, when I run less /etc/passwd I see this entry sddm:x:964:964:SDDM Greeter Account:/var/lib/sddm:/usr/bin/nologin. Means that before the user logs in, an xauth file for sddm is created (probably via this the login screen is displayed).
The fiddling around is already a bit tiring, that’s why I seem to overlook some obvious things & checks, so thanks again for the hint.
Now the question arises, can sddm be started via the user dev (in my case) with UID:GID 1000:1000, then the issue would be cleanly solved.
Because then the login screen itself would run via the desktop user and after logging in the same user would just render different things (the Desktop instead of the Login screen), thus the nextcloud application (plus tray icon) should embed properly.
Another thought would be to start nextcloud as sddm user and after logging in transfer the started app to UID 1000 (but that needs further research, whether that is conceptually possible at all).

Ubuntu 24 btw uses gdm3 and does not right away allow starting xeyes on system startup (same error with not accessible DISPLAY when using systemd), gdm3 startup script /etc/gdm/Init/Default also does not solve this.

Next attempt: run nextcloud as user sddm via systemd …

–

Ok… I am giving up, and use nextcloudcmd instead.

13

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.