Hi guys!
After every reboot of my system
the 'user' file at
run/user/1000/dconf/user
has root user rights (user+group)
instead of my username.
How revert it back to my username permanent?
Found only that workaround:
sudo chown username:username /run/user/1000/dconf/user
Only unfortunately as mentioned before after a reboot of my system root is again displayed as user and group in
/run/user/1000/dconf/user
entered.
Please help, thanks!
Hmm... I've only ever seen this happen right after I've run a graphical application as root (using sudo) on my normal user's desktop. For example, if I run:
sudo pluma /etc/fstab
...and then open the Pluma Preferences dialog and change something, often the ownership of my /run/user/[nnnn]/ directory changes to root. Then I can't change any preferences for my applications running as my normal user until I change the ownership back!
I've seen the above phenomenon occur much more frequently when I run a command as root on my Wayland desktop than on my Xorg desktop. I don't know why that happens, honestly.
However, from how you're describing the situation, that file gets switched over to root ownership every reboot. I've never seen that before. However...
I do know from my past experience with you that you tweak around with your boot files (especially SystemD Init boot files). Have you added any SystemD boot files or services which use dconf, gsettings or some other means to change user preferences every boot-up? Because if you are, I'd like to know exactly what you're trying to change -- there's probably another way to go about it, and using dconf or gsettings as root to change another user's settings is not the best idea in the world.
If you have to use the dconf or gsettings tool for your situation, I'd suggest adding a line like this to your service file, right below the last use of the settings-changing command:
chown 1000:1000 /run/user/1000/dconf/user
Alternatively, you could look into using the User= directive in your service / unit file, to make the service run as your normal user -- just add a line like:
User=[username]
Finally, you might try invoking the settings-changing command(s) using sudo --user, like this:
sudo --user [username] gsettings set org.mate.interface gtk-overlay-scrolling false
I hope that helps. And, who knows what kind of useful advice @tkn is writing right now (I see @tkn is replying to your post as I type this, too)?
Like @gordon wrote: somewhere in your autostart-files there is probably some command being started like
sudo dconf
sudo gsettings
Which should be without 'sudo'
And to make the chaos complete:
Quote:
The issue can be caused by running a GUI after changing user using
sucommand. Certain environmental variables are not changed causing the error. See
(b.t.w.: note the date of that bug)
That means that if you run sudo dconf
you expect it to write to /run/user/0/dconf/user
but instead it writes to /run/user/1000/dconf/user
because 'sudo' elevates permissions, but it does not impersonate root.
Solution:
Don't run gsettings or dconf as elevated user (i.e. 'su' or 'sudo') in an autostart script.
But, if you really need to do that, also adjust XDG_RUNTIME_DIR
What irritates me,
dconf-editor without su/sudo = settings for the default user?
su/sudo dconf-editor = settings for the root user?
Without and with su/sudo dconf-editor I have 2 different desktop settings stored in dconf-editor.
dconf-editor without su/sudo = settings for the default user?
Yes
su/sudo dconf-editor = settings for the root user?
Yes
Without and with su/sudo dconf-editor I have 2 different desktop settings stored in dconf-editor.
Yes but No: Nothing is actually stored in dconf-editor , settings are stored in configuration files that can be read, edited and written by dconf-editor.
Here are the configfiles stored:
- user -> $HOME/.config/dconf/user
- root -> /root/.config/dconf/user
The file /run/user/1000/dconf/user is only a temporary file, I assume to track live changes.
It is a bit unlucky that a 'su/sudo' also uses that same temporary file.
@ tkn,
I have turned off my root account and only use sudo to make settings on my system.
If I want to further optimize my desktop settings, then I only need to run "dconf-editor" for my default user in my system? Right?
Or would I also need to use "sudo dconf-editor" to optimize my system?
I also ask because it is a lot of work to look through all the entries with the "dconf-editor" and it would make me work twice as hard if I do this with sudo dconf-editor for the root account as well.
File:
/root/.config/dconf/user = is only used by desktop login via root account, right?
Well, yes I suppose so, because I never used sudo with dconf-editor and i don't have the impression that i'm missing out on something.
If I want some global settings changed, like the desktop-manager settings, it asks me for a password when needed. But that is something that I don't use dconf-editor for anyway.
No, it is also used by sudo.
if you sudo a random MATE application ( like, for instance, pluma) and you change the settings, the system will store them in /root/.config/dconf/user
Here is an example setting (pluma colors) of both side by side:
Hi,
username hasn't root user rights
Hi Jorge,
Welcome 
It's not quite clear to me what you want to ask but I'll try to answer anyway.
That is correct, you do not want every user to be administrator on your system. This is by design.
That is indeed the way to logon via loopback to your own machine
error: too many arguments
In other words:
If you read a dconf key, you should not supply a value to the key because you are instead asking the system to obtain the value for you.
P.S. I have the slight feeling that I don't quite get what you are asking. I hope you can enlighten me a bit more.
