What are the causes of permission errors for /run/user/NNNN/dconf/user files? How can we resolve them?

Question

There are several open questions regarding GUI apps whose console output shows repeated errors similar to the following:

(XXXX:YYYY): dconf-CRITICAL **: unable to create file '/run/user/NNNN/dconf/user': Permission denied.  dconf will not work properly.

or

(XXXX:YYYY): dconf-CRITICAL **: unable to create directory '/run/user/NNNN/dconf': Permission denied.  dconf will not work properly.

Where XXX is an application name, YYY is a number, and NNN is a user id number (?).

• unable to create directory '/run/user/7093511/dconf': Permission denied. dconf will not work properly
• Getting "unable to create file '/run/user/1000/dconf/user': Permission denied" (due disclosure: An issue of mine from 3 years ago)
• Mate desktop breaks with no panels and tens of caja windows on user switching?
• dconf fails when running X application from alternate user
• Black screen on vnc and grey screen on iLo, possible /run/user/1000/dconf/user problem?

And these often remain unanswered, or with answers which don't resolve the issue (or possibly unresponsive posters).

I was hoping to attract enough community attention to this question (perhaps with a bounty if necessary) to provide proper description of the possible causes of this issue, and a list of several actions which should resolve, say in 90% of cases, so that in the future one could easily mark yet another variant of these questions as a duplicate of this one.

Answer 1

The simplest cause is that the entire /run/user/<UID> directory does not exist – it hasn't been created by systemd-logind, typically because the UID in question hasn't gone through the standard "user login" procedures, but was merely su'd or sudo'd to, without invoking pam_systemd.

("Permission denied" comes from dconf's attempting to mkdir all the parent directories, which it cannot do because /run and /run/user themselves are only writable by root.)

This directory is created when at least one session for that UID is created – and similarly, it will be deleted when systemd-logind sees a user's session count drop to 0. For example, in one of your posts, using su -l instead of su may solve the problem because it makes su use a different PAM configuration, one where pam_systemd is enabled.

So if the error message begins showing up for your own UID while using your desktop via VNC, then it likely means that the entirety of the VNC process tree exists outside of any systemd-logind "session" (i.e. PAM wasn't used while starting the VNC server) and therefore isn't part of the reference-count that would prevent systemd-logind from deleting the /run/user/<UID> directory upon logout.

(For example, if you connect to a remote host via SSH, the user runtime directory is created; then you start something like "vncserver.service" and everything seems fine; but as soon as you disconnect from SSH, the runtime directory is deleted again because that was your last session.)

(You can see this in journalctl, possibly indirectly – the runtime directory is created/deleted at the same time when the "systemd --user" instance, named "User Manager for UID <UID>", is started/stopped.)

In those situations, one way to make the runtime directory "permanent" is to set systemd-logind's linger flag for that user, using loginctl enable-linger <USERNAME>. This will cause that user's runtime directory (and their systemd --user instance) to be started on boot and kept around until shutdown.

Alternatively, if VNC is being started via systemd, its .service's PAMName= parameter should be used to create a full PAM session which will register with systemd-logind and will cause the runtime directory to be created as long as the VNC .service is running.

---

A second related cause is that dconf is being told to use another user's runtime directory. The "/run/user/<UID>" pattern isn't determined by dconf directly – instead the whole path is taken from your XDG_RUNTIME_DIR environment variable that's set by PAM.

If you use something like sudo -E to run graphical programs as a different user, they will inherit all of your environment – they might be able to live with your $HOME if it is world-readable, but they will not be able to use your $XDG_RUNTIME_DIR as it is only accessible by you (by design).

The solution is "don't do that", i.e. don't make programs run under other UIDs inherit your $XDG_RUNTIME_DIR and related environment. Specifically for dconf, it will fall back to the user's ~/.cache/dconf if it needs to (although this assumes it didn't inherit the wrong $HOME, either).

Answer 2

su -l username -c "(export DISPLAY=:5; dbus-launch --exit-with-session; vncserver -geometry 1792x899 -depth 24 :5)"

The command "dbus-launch --exit-with-session" sets dbus variables to be specific to the user running vncserver, otherwise it might pick them up from somewhere else or not have them set at all. These need to set correctly of you will get a blank screen or permission denied. For example

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1003/bus

Answer 3

Debian Stretch

My xsession-errors files were sometimes blowing up with over half a million of subject lines during a 12-hour session (I could view the carnage as it was happening in a terminal window using tail -f -n +1 .~/xsession-errors | nl - a temporary mitigation was to run chown -R 1000:1000 /run/user/1000/*. but, still...) Here is a summary of what I did to stop these from occurring:

First, I scrubbed all of my personal scripts, desktop files, and keyboard shortcut snippets for incidences of su and gksu commands, replacing same with su -l and gksu -l commands. Also, I use Xfce and there were a few /usr/share/applications/ desktop files (mostly ones that I'd created/modified) that needed to be so changed.

Then, since at least one of my user desktop files invoke the su-to-root executable (found in Debian's menu package), I copied /usr/bin/su-to-root to /usr/local/bin/ and renamed same to "su-to-root-gksu-l". Then, in said file, I replaced the following line:

gksu) gksu -u "$PRIV" "$COMMAND";;

with

gksu) gksu -l -u "$PRIV" "$COMMAND";;

Next, I scrubbed all of my personal scripts, desktop files, and keyboard shortcut snippets for the usage of said su-to-root executable and changed any references to same to su-to-root-gksu-l. I did find some desktop files in /usr/share/applications/ that used the su-to-root script, but made no changes in them, as I did not see the need. I also scrubbed all of my Thunar custom actions.

Finally, I created a system-wide alias, of sorts (inserted into the etc/bash.bashrc file): function su() { if [[ $1 == "--" ]]; then command su "$@"; else command su -l "$@"; fi; }

FYI, there is additional discussion of this shell function here.