VNC Session would not start KDE: QStandardPaths: wrong ownership on runtime directory

English Applications
1

Hello everybody,

I have Leap 15.1 installed on a Workstation where multiple users access the graphical environment (KDE) through a VNC-connection. Everything worked fine until around two weeks ago (I cannot really say, because the problem was first noticed after some reboots). The issue is as follows:

When I log into the system (via SSH) a directory is created: /run/user/1000 (1000 is my uid). Then I start a VNC-Server and all works fine for me. But if another user logs in and starts a VNC-Session, it wants access to /run/user/1000 which obviously creates an error, as this directory is already owned by me. It makes no difference if I create the directory for the user and change its owner (e.g. mkdir /run/user/1001 followed by chown to this user), it persistently wants access to /run/user/1000.

Now the very funny behavior: if I let 3 or 4 users to log in before me (e.g. after a fresh start), then their respectively directories will be created and they will be able to run their VNC-Sessions as usual. If I then log in, the directory /run/user/1000 is created and no further user can start a VNC-Session (all previously logged users can continue working without problems).

I tried to trick the system by changing my uid, so now I’m uid=1012. But this didn’t change anything, now all users wants access to /run/user/1012. Interestingly, this only happens with my user, e.g. if user 1001 starts, then user 1002 will not try to get access to /run/user/1001. But as soon as I start, everyone wants access to /run/user/1012.

Here the log file for the VNC-Session of user uid=1009 (when I was already logged in with uid=1012):

Mon Dec 9 13:23:39 2019
vncext: VNC extension running!
vncext: Listening for VNC connections on all interface(s), port 5902
vncext: created VNC server for screen 0
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86WWAN
> Internal error: Could not resolve keysym XF86RFKill
Errors from xkbcomp are not fatal to the X server
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
kcm_input: Using X11 backend
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
startkde: Starting up…
kdeinit5: Aborting. bind() failed: Permission denied
Could not bind to socket ‘/kdeinit5__2’
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
kdeinit5_wrapper: Warning: connect(/kdeinit5__2) failed: : No such file or directory
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
Qt: Session management error: networkIdsList argument is NULL
Configuring Lock Action
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
ksmserver: “/KSMserver”
ksmserver: KSMServer: cannot open /KSMserver__2: Permission denied
ksmserver: KSMServer: Aborting.
startkde: Shutting down…
QStandardPaths: wrong ownership on runtime directory /run/user/1012, 1012 instead of 1009
kdeinit5_wrapper: Warning: connect(/kdeinit5__2) failed: : No such file or directory
Error: Can not contact kdeinit5!
startkde: Done.

After this, the user in this example (uid=1009) tries to connect to the VNC-Server but only gets a black screen with the mouse pointer. In some cases also a warning appears: Could not sync environment to dbus (no luck searching for that!)

All best,
Daniel

Opensuse LEAP 15.1
KDE + Plasma
Dell Precision Workstation
Is this a new bug?

2

First,
There are a multitude of ways for VNC to be deployed,
So you’ll have to describe how your VNC server is set up.

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

The TigerVNC online documentation
The TigerVNC MAN pages

of which all of the above don’t necessarily cover the same ground,

I’m also preparing a re-write which I hope will better organize and explain the LEAP documentation.
At the moment though, what I’ve posted is very “Alpha” in that the text is not finalized, there are no images and there is no formatting to “pretty” up and clarify certain test like commands
https://en.opensuse.org/User:Tsu2/remote_administration_VNC

You <might> find that the re-organization even in my early re-write might clarify some differences in how VNC can be deployed… eg non-persistent vs persistent “User” setups and how you logon and secure your connection which I suspect relates directly to accessing resources from your VNC connection.

Since my documentation is still very Alpha, I’d expect some things need to be explained much better, so just post.

TSU

3

Hi,

oh, yeah, the good old documentation. Sorry, I forgot to mention that I’m since 15 years using Linux and of course I have already read all possible documentations and did research on many forums. Specifically your documentation was new to me, but the only new thing I found there was the option to tunnel the VNC port on SSH. Of course, this has nothing to do with my specific problem.

To your inquiries, our way to set up VNC and connect to it is pretty standard and straight forward:

Start a console via SSH:
> ssh ip-number -l username

Start a VNC session with TigerVNC:
> vncserver

Connect to the VNC session with TigerVNC-Client. A VNC passwort is asked before graphical session starts:
> vncviewer ip-number:session-number

VNC is persistent as many tasks must continue running for many hours or days, and the users reconnect to check if it’s done or not.
In the firewall I have opened the TCP ports 5901 to 5915 (just to limit the amount of running sessions).
I did not use YAST module to start VNC.

Hope this helps you well… I’m still trying to solve this, without any progress…

Thanks,
Daniel

4

Are your Users connecting to the same persistent connection running on the assigned port (and display), and not running their own sessions on different ports?

TSU

5

Hi,
there are 11 users (uid 1000 to 1011), everyone of them opens its own session in a first-come-first-serve basis, so the session number does not necessarily correspond to the uid. As I kinda admin the System, normally I’m the first one to log in, so uid=1000 correspond to VNC:1, but this is not a must.

Daniel

6

Hi floks,

here some news. Didn’t find the solution, but at least a workaround:

cd ~
mkdir .XDG_RUNTIME_DIR
export XDG_RUNTIME_DIR=/home/lindanux/XDG_RUNTIME_DIR
export $(dbus-launch)

Thanks fperal for the hint on this post :wink: