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

最も簡単な理由は、/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も継承しないと仮定します）。

su -l ユーザー名 -c "(エクスポート DISPLAY=:5; dbus-launch --exit-with-session; vncserver -geometry 1792x899 -深さ 24:5)"

"dbus-launch --exit-with-session"コマンドは、vncserverを実行しているユーザーに関連するdbus変数を設定します。それ以外の場合は、他の場所でその変数を取得したり、まったく設定しない可能性があります。正しく設定する必要があります。それ以外の場合は、黒い画面が表示されるか、権限が拒否されます。例えば

DBUS_SESSION_BUS_ADDRESS=UNIX:パス=/run/user/1003/バス

Debian ストレッチ

私の12時間セッションの間、私のxsession-errorsファイルは時々500,000を超えるタイトル行でいっぱいになりました（tail -f -n +1 .~/xsession-errors | nl私が使用できる一時的な緩和方法は、ターミナルウィンドウで大虐殺が起こるのを見るために実行することでしたが、chown -R 1000:1000 /run/user/1000/*それでもそうです）。 ..).このような状況が発生しないように、私が取るアクションを要約すると、次のようになります。

suまず、すべてのプライベートスクリプト、デスクトップファイル、およびキーボードショートカットの断片をクリーンアップして、andコマンドが出てくる場所を見つけてandコマンドgksuに置き換えました。また、私su -lgksu -lXfce少し残った/usr/共有/アプリケーション/これは変更する必要があるデスクトップファイル（主に私が作成/変更するファイル）です。

その後、ユーザーデスクトップファイルに1つ以上の呼び出しがあるため、ルートにsu実行ファイル（Debianにあります）メニューパッケージ）、コピーしました/usr/bin/suをrootにする到着/usr/ローカル/空/そして名前を」su-root-gksu-l」。その後、そのファイルで次の行を置き換えました。

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

そして

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

次に、上記の内容を使用するために、すべてのプライベートスクリプト、デスクトップファイル、およびキーボードショートカットの一部をクリーンアップしました。ルートにsu実行可能ファイルを作成し、同じコンテンツへの参照を次に変更します。su-root-gksu-l。私したデスクトップファイルが見つかりました/usr/共有/アプリケーション/使用されるルートにsuスクリプトを作成しましたが、必要ないと思って変更しませんでした。私も全部クリアしました。トゥナードカスタムアクション。

最後に、システム全体のエイリアスを作成しました（等/bash.bashrc文書）：function su() { if [[ $1 == "--" ]]; then command su "$@"; else command su -l "$@"; fi; }

ちなみに、このシェル機能に関する追加の議論があります。ここ。