☰

/run/user/NNNN/dconf/user ファイル権限エラーの原因は何ですか？どうすれば解決できますか？

tag-icon • tag-icon permissions dconf
/run/user/NNNN/dconf/user ファイル権限エラーの原因は何ですか？どうすれば解決できますか？

コンソール出力に次のような繰り返しエラーが表示される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％の場合）。 ）今後、人々はこれらの質問の別のバリエーションをこの質問の重複として簡単に表示することができます。

ベストアンサー1

最も簡単な理由は、/run/user/<UID>ディレクトリ全体が存在しないことです。これはsystemd-logindによって生成されませんでした。これは通常、問題のUIDが標準の「ユーザーログイン」プロセスを経ずに単にsu「d」またはsudo「」になっているためです。 pam_systemdを呼び出さずに入りました。

（「拒否されました」は、dconfがすべての親ディレクトリをmkdirしようとしたときに発生しますが、/runと/run/user自体はrootでのみ書き込むことができるため、そうすることはできません。）

このディレクトリは、そのUIDのセッションが1つ以上作成されたときに作成されます。同様に、systemd-logind でユーザーのセッション数が 0 に低下することを確認すると、削除されます。たとえば、投稿の1つで代わりにsu -lを使用すると、susuが別のPAM設定を使用するため、問題は解決されます。ここで pam_systemdはい有効です。

したがって、VNCを介してデスクトップを使用するときに独自のUIDでエラーメッセージを表示し始めると、VNCプロセスツリー全体がsystemd-logind "セッション"の外側にあることを意味します（つまり、VNCサーバーを起動するときにPAMが使用されないなかった）。したがって、systemd-logindがログアウト時にディレクトリを/run/user/<UID>削除するのを防ぐ参照カウントの一部ではありません。

（たとえば、リモートホストにSSHで接続すると、ユーザーのランタイムディレクトリが作成されます。次に、「vncserver.service」のようなものを起動するとすべてが正常に見えますが、SSH接続を切断するとランタイムディレクトリが再び削除されます。セッションだった）。

（おそらく間接的に表示されますjournalctl。 - 「UID <UID>のユーザーマネージャ」という名前の「systemd --user」インスタンスが起動/停止されると、ランタイムディレクトリが同時に作成/削除されます。）

そのような場合、ランタイムディレクトリを「永続」にする1つの方法は、systemd-logindを設定することです。引きずらせるを使用してこのユーザーのフラグですloginctl enable-linger <USERNAME>。これにより、そのユーザーのランタイムディレクトリ（およびそのインスタンスsystemd --user）が起動時に開始して終了するまで保持されます。

または、VNCがsystemdを介して起動された場合は、PAMName=.serviceパラメータを使用して完全なPAMセッションを作成する必要があります。このパラメータはsystemd-logindに登録し、VNC .serviceが実行されたときにランタイムディレクトリを生成します。

2番目の関連理由は、dconfに次のように指示されたためです。他のユーザーのランタイムディレクトリ。 "/run/user/<UID>"パターンはdconfによって直接決定されません。代わりに、フルパスはXDG_RUNTIME_DIRPAMによって設定された環境変数から取得されます。

他のユーザーとしてグラフィックプログラムを実行するのと同じ機能を使用すると、sudo -Eすべての環境を継承します。 $HOMEが誰でも読むことができれば作業できますが、$XDG_RUNTIME_DIRをそのまま使用することはできません。 （設計上）あなただけがアクセスできます。

解決策は「しないでください」です。つまり、他の UID で実行されるプログラムが $XDG_RUNTIME_DIR と関連環境を継承しないようにすることです。特にdconfの場合、必要に応じてユーザーの~/.cache/dconfに置き換えられます（もちろん、間違った$ HOMEも継承しないと仮定します）。

おすすめ記事