关于 GUI 应用程序有几个悬而未决的问题，其控制台输出显示类似于以下内容的重复错误：
(XXXX:YYYY): dconf-CRITICAL **: unable to create file '/run/user/NNNN/dconf/user': Permission denied. dconf will not work properly.
或者
(XXXX:YYYY): dconf-CRITICAL **: unable to create directory '/run/user/NNNN/dconf': Permission denied. dconf will not work properly.
其中 XXX 是应用程序名称，YYY 是数字，NNN 是用户 ID 号 (?)。
这些问题往往没有得到答复，或者得到的答案不能解决问题（或者可能是没有反应的海报）。
我希望引起社区对这个问题的足够关注（如果必要的话可能会提供赏金），以提供对该问题的可能原因的正确描述，并列出应该解决的几个行动（例如在 90% 的情况下），以便将来，人们可以轻松地将这些问题的另一种变体标记为与此问题重复。
最简单的原因是整个/run/user/<UID>目录不存在 \xe2\x80\x93 它不是由 systemd-logind 创建的，通常是因为有问题的 UID 没有经过标准的“用户登录”过程，而仅仅是su'd 或sudo'd to，而不调用 pam_systemd。
（“权限被拒绝”来自 dconf 尝试 mkdir 所有父目录，但它无法执行此操作，因为 /run 和 /run/user 本身只能由 root 写入。）
\n当至少为该 UID 创建一个会话 \xe2\x80\x93 时，就会创建此目录，类似地，当 systemd-logind 看到用户的会话计数降至 0 时，该目录将被删除。例如，在您的一篇文章中，使用su -l而不是su可以解决问题，因为它使 su 使用不同的 PAM 配置，即启用 pam_systemd 的配置。
因此，如果在通过 VNC 使用桌面时开始显示您自己的 UID 的错误消息，则可能意味着整个 VNC 进程树存在于任何 systemd-logind“会话”之外（即启动时未使用 PAM） VNC 服务器），因此不是引用计数的一部分，这会阻止 systemd-logind/run/user/<UID>在注销时删除目录。
（例如，如果您通过 SSH 连接到远程主机，则会创建用户运行时目录；然后您启动类似“vncserver.service”的内容，一切看起来都很好；但是一旦您与 SSH 断开连接，运行时目录就会被删除再次因为那是你的最后一次会议。）
\n（您可以在 中看到这一点journalctl，可能间接 \xe2\x80\x93 当名为“UID <UID> 的用户管理器”的“systemd --user”实例启动时，同时创建/删除运行时目录/停了。）
在这些情况下，使运行时目录“永久”的一种方法是使用loginctl enable-linger <USERNAME>. 这将导致该用户的运行时目录（及其systemd --user实例）在启动时启动并保留到关闭为止。
或者，如果通过 systemd 启动 VNC，PAMName=则应使用其 .service 参数创建完整的 PAM 会话，该会话将向 systemd-logind 注册，并在 VNC .service 运行时创建运行时目录。
第二个相关原因是 dconf 被告知使用另一个用户的运行时目录。“/run/user/<UID>”模式不是由 dconf 直接 \xe2\x80\x93 确定的，而是从XDG_RUNTIME_DIRPAM 设置的环境变量中获取整个路径。
如果您使用诸如sudo -E以不同用户身份运行图形程序之类的东西，它们将继承您的所有环境 \xe2\x80\x93 如果它是世界可读的，它们可能能够与您的 $HOME 一起使用，但它们将无法使用您的 $XDG_RUNTIME_DIR 因为它只能由您访问（根据设计）。
解决方案是“不要这样做”，即不要让在其他 UID 下运行的程序继承您的 $XDG_RUNTIME_DIR 和相关环境。特别是对于 dconf，如果需要，它将回退到用户的 ~/.cache/dconf（尽管这假设它也没有继承错误的 $HOME）。
\n