dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Keine Berechtigung. dconf will not work properly

[raa]

Hier ist was darüber:
https://bugzilla.redhat.com/show_bug.cgi?id=921689
und
https://lists.debian.org/debian-user/20 ... 01062.html

Hm, was sagt du denn dazu:

https://bugzilla.redhat.com/show_bug.cgi?id=921689#c18

(In reply to Ari Lemmke from comment #17)
if you are have an fas account or something like this, you should be able to reopen this bug, is not need great permissions. I won't open it because don't know if it is a bug really.

IIRC this is almost an inoffensive warning and as comment #8 states :

export XDG_RUNTIME_DIR=/run/user/1000

fixes the warning for me ...

Schön, die Warnung war gefixt - und der Bug?

Jedenfalls werd' ichs mal mit dieser Umgebungsvariable versuchen - mehr kaputtmachen kann man damit doch nicht, oder? Die Frage wäre nun noch, wo die hingehört - in /home/hk/.bashrc, /root/.bashrc oder am besten in beide ...

[raa]

Also des Rätsels Lösung: Das sind keine fehlenden Rechte des Users in dem Verzeichnis /run/user/1000/dconf, sondern eine bereits existierende Datei /run/user/1000/dconf/user mit Root als Eigentümer. Hat einer 'ne Ahnung, wie die dahin kommt?

[DeletedUserReAsG]

Sowas passiert üblicherweise, wenn man Sachen mit diesem unsäglichen (in der Konfiguration nach Buntu-Art, nicht per se) sudo startet. Dann werden Verzeichnisse des Users genommen, aber Files mit Rootrechten erstellt. Ist nicht das erste Mal, dass jemand drüber stolpert.

[raa]

Hm, und wie kann man das ändern?

Oder anders: Wenn eine /run/user/1000/dconf/user mit dem User als Eigentümer einmal drinsteht (wie jetzt), wird die dann wieder überschrieben?

[smutbert]

Nachdem das ganze (»/run«) auf einem tmpfs, also einem Dateisystem im Hauptspeicher, liegt, verschwindet das falsche Verzeichnis beim nächsten Neustart.
(Alternativ sollte es genügen sich abzumelden, alle Prozesse des Benutzers zu beenden, gegebenenfalls auch die mit su/sudo/gksu/kdesudo gestarteten, die an der Misere schuld sind, das Verzeichnis »/run/user/1000« zu löschen und sich wieder anzumelden, aber in den meisten Fällen ist ein Neustart einfacher.)

[raa]

Naja, das ist auch umständlich. So habe ich mir nun beholfen:

- Die "/usr/bin/gksu" umbenannt in "gksu.bin"

- Ein kleines Script "gksu.sh" erstellt:

Code: Alles auswählen

#!/bin/bash

gksu.bin "$*"; CC=$?

[ $CC = 255 ] && exit $CC

file=/run/user/1000/dconf/user

gksu.bin "chown hk $file"; gksu.bin "chgrp hk $file"

(Ausführbar machen nicht vergessen.)

- Unter /usr/bin/ einen Symlink "gksu" auf das Script angelegt, so dass jetzt mit "gksu <irgendein Programm>" das Script aufgerufen wird.

Funzt.

[raa]

Sowas passiert üblicherweise, wenn man Sachen mit diesem unsäglichen (in der Konfiguration nach Buntu-Art, nicht per se) sudo startet. Dann werden Verzeichnisse des Users genommen, aber Files mit Rootrechten erstellt. Ist nicht das erste Mal, dass jemand drüber stolpert.

"gksu", nicht "sudo". Da habe ich eine Weile an der falschen Stelle gesucht.

Nachdem das ganze (»/run«) auf einem tmpfs, also einem Dateisystem im Hauptspeicher, liegt, verschwindet das falsche Verzeichnis beim nächsten Neustart.
(Alternativ sollte es genügen sich abzumelden, alle Prozesse des Benutzers zu beenden, gegebenenfalls auch die mit su/sudo/gksu/kdesudo gestarteten, die an der Misere schuld sind, das Verzeichnis »/run/user/1000« zu löschen und sich wieder anzumelden, aber in den meisten Fällen ist ein Neustart einfacher.)

Naja, das ist auch umständlich, da ich ständig einige Programme am Laufen habe (und die Kiste üblicherweise in den Ruhezustand schicke, damit sie gleich wieder da sind). So habe ich mir nun beholfen:

- Die "/usr/bin/gksu" umbenannt in "gksu.bin"

- Ein kleines Script "gksu.sh" erstellt:

Code: Alles auswählen

#!/bin/bash

gksu.bin "$*"

file=/run/user/1000/dconf/user

gksu.bin "chown hk $file"; gksu.bin "chgrp hk $file"

(Ausführbar machen nicht vergessen.)

- Unter /usr/bin/ einen Symlink "gksu" auf das Script angelegt, so dass jetzt mit "gksu <irgendein Programm>" das Script aufgerufen wird.

Funzt.