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

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

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

Beitrag von raa » 18.04.2018 06:02:51

Hm, was sagt du denn dazu:

https://bugzilla.redhat.com/show_bug.cgi?id=921689#c18
Sergio Monteiro Basto hat geschrieben:(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? :wink:

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

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

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

Beitrag von raa » 05.05.2018 21:32:13

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

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

Beitrag von DeletedUserReAsG » 05.05.2018 21:56:58

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
Beiträge: 411
Registriert: 19.12.2013 10:16:19

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

Beitrag von raa » 06.05.2018 10:17:18

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?

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

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

Beitrag von smutbert » 06.05.2018 10:52:04

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
Beiträge: 411
Registriert: 19.12.2013 10:16:19

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

Beitrag von raa » 22.09.2018 08:46:03

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.) :wink:

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

Funzt. :wink:

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

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

Beitrag von raa » 22.09.2018 09:26:05

niemand hat geschrieben: ↑ zum Beitrag ↑
05.05.2018 21:56:58
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. :wink:
smutbert hat geschrieben: ↑ zum Beitrag ↑
06.05.2018 10:52:04
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.) :wink:

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

Funzt. :wink:

Antworten