VNC with SDDM (or xdm) with not root user

Starting from https://forums.opensuse.org/showthread.php/539166-Replacing-SDDM for a better clarity,
I open this new thread because may issue is not completely connected to SDDM but it seems more connected to VNC.

I want to run a VNC server as normal user and connect to it with a remote PC.
The PC server has as display manager SDDM (but I’ve tried also with xdm with same results).
As normal user (on PC server) I run the command :


icai@CITECT:~> vncserver :1 -geometry 1024x768 -depth 24

New 'CITECT:1 (icai)' desktop is CITECT:1

Starting applications specified in /home/icai/.vnc/xstartup
Log file is /home/icai/.vnc/CITECT:1.log

I also created a password to access to it.
This is the content of /home/icai/.vnc/xstartup :


#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

userclientrc=$HOME/.xinitrc
sysclientrc=/etc/X11/xinit/xinitrc

if  -f "$userclientrc" ]; then
  client="$userclientrc"
elif  -f "$sysclientrc" ]; then
  client="$sysclientrc"
fi

if  -x "$client" ]; then
  exec "$client"
fi
if  -f "$client" ]; then
  exec sh "$client"
fi

 -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
if  -x /usr/bin/twm ]; then
  /usr/bin/twm &
else
  echo "No window manager found. You should install a window manager to get properly working VNC session."
fi

This is the output of lsof:


lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
kdeconnec 2384                      icai   13u     IPv6              32112      0t0        TCP *:xmsg (LISTEN)
kdeconnec 2384 2395 QXcbEvent       icai   13u     IPv6              32112      0t0        TCP *:xmsg (LISTEN)
kdeconnec 2384 2411 QDBusConn       icai   13u     IPv6              32112      0t0        TCP *:xmsg (LISTEN)
kdeconnec 2384 2413 Qt\x20bea       icai   13u     IPv6              32112      0t0        TCP *:xmsg (LISTEN)
Xvnc      2985                      icai    6u     IPv4              56819      0t0        TCP *:5901 (LISTEN)
Xvnc      2985                      icai    7u     IPv6              56820      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2986 llvmpipe-       icai    6u     IPv4              56819      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2986 llvmpipe-       icai    7u     IPv6              56820      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2987 llvmpipe-       icai    6u     IPv4              56819      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2987 llvmpipe-       icai    7u     IPv6              56820      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2988 llvmpipe-       icai    6u     IPv4              56819      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2988 llvmpipe-       icai    7u     IPv6              56820      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2989 llvmpipe-       icai    6u     IPv4              56819      0t0        TCP *:5901 (LISTEN)
Xvnc      2985 2989 llvmpipe-       icai    7u     IPv6              56820      0t0        TCP *:5901 (LISTEN)

On a remote PC (with SDDM) as normal user I run


vncviewer :1

I give the vnc password and I get back a black screen (I get this with SDDM or xdm on PC server).

When I do the same steps but with root (on PC server) everything work (with SDDM or xdm on PC server).

IMHO I believe that the issue is not related to display manager but maybe is related to some kind of permission …

First,
Even if you’re writing code only for yourself,
It’s likely good SOP to exhaustively document your code with comments…
You’ll never know if you don’t look at your code again for a few years, when you read your code written long ago you might find it difficult to follow what you wrote.

When you post for others to see, you’ll help them out so that even script newbies can try to understand what you wrote.

As for you question…
Unless I’m mistaken, looks to me that when you’re logged in as a regular User, you can access your scripts (and other assets) with your User path, but when you login as root the User path will be different and your script, assets and anything else isn’t going to be found.
Although you describe success invoking vncserver manually and using your code,
You might want to consider configuring your VNC server to run as a service instead, and specify your display parameters differently (depends on what type of connections you want to support). I don’t remember in the documentation specifying some way of restricting access to applications, that’s normally done differently by a policy.

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-vnc.html

TSU

At the end the solution was not so far from here : https://forums.opensuse.org/showthread.php/532320-vncserver-blank-screen/page2

Quickly, the trick is to modify the file .vnc/xstartup in that way :


if  -x "$client" ]; then 
#  exec "$client"  
  dbus-launch --exit-with-session "$client"
fi
if  -f "$client" ]; then
#  exec sh "$client"  
  dbus-launch --exit-with-session sh "$client"
fi

It seems that starting from Leap 15.0 has been changed something (dbus-launch vs exec) but vncserver (the process who creates the file xstartup) doesn’t know that.

You made that really hard didn’t you Max? If only you had looked at the supplied documentation:
openSUSE Leap Documentation › Reference › Advanced Administration › Remote Graphical Sessions with VNC
(also online at: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-vnc.html }

Right at the beginning in a large alert box:
“A machine can reliably accept VNC connections only if it uses a display manager that supports the XDMCP protocol. While gdm, lxdm, or lightdm support XDMCP, the KDE 5 default display manager sddm does not support it.”

Which explains the black screen with SDDM. I used LightDM

YaST2 > Miscellaneous > Alternatves > default-displaymanager

Then setup the VNC server:
YaST2 > Network Services > Remote Administration (VNC)

It all takes about two minutes including looking up the argumentation and help dialogue.
The main advantage of SuSE/openSUSE for over 20 years has been that administration has been made easy (once you work out, or someone tells you, what it is that you actually want to do).