Some KDE setting are not saved upon system restart

After updating to the latest 20.1 KDE version I started seeing some bugs that relate to KDE.

For example, on my installation there is no default shortcut assigned to the Launch Konsole action in Custom shortcuts. So I have to assign it on my own. The problem is that this assignment is always reset every time I restart my computer. I tried giving ~/.config/khotkeysrc file 444 (read only) and 777 (full access) permssions, neither of which has helped.

Similarly, the Klipper shows up the annoying popup every time I Ctrl+A a URL link. Even though I select Disable This Popup, it will still start showing up on the next system restart.

So it’s clear to me now that it is not the issue of those individual application but rather the system setup itself. So I was wondering how can I troubleshoot this issue? Or are supposed to do clean-install every time a major version is released?

CTRL+ALT+T by default on KDE and most desktop environment.


After this discussion

you should check permission on ~/.config/khotkeysrc and also on ~/.config/kglobalshortcutsrc

1 Like

Thanks, setting 666 on ~/.config/kglobalshortcutsrc did the trick for me and Konsole shorcut is now saved after restart. Similarly, setting 666 on ~/.config/klipperrc saves the disabled popup option.

I guess now I see the pattern, my config files lost the rw permissions after the update. Thanks again.

1 Like

That must have been something you did yourself - package updates won’t touch any files in your $HOME.

While 666 will work, it’s too much: 400 (edit) 600 is enough - only the owner needs rw.

1 Like

Indeed, but then shouldn’t it be 600, as opposed to 400?

I initially had 400 and that was the thing preventing me from saving my settings.

1 Like

Right you are, I’ve corrected that post. That’s why I almost always use the other form - easier to see what permissions are set:

$ chmod -rwx,u+rwX ~/.config -R

That’s weird I had a look and I have almost no file with the execution bit set :D, only what seems to be some kind of scripts have +x but otherwise, relatively no file in .config have +x. But yeah u+rwx makes no harm and gives +x to the files needing it, in my case which are (I excluded folders with +x here is only the files):

find ~/.config/ -executable -type f

Note the uppercase X - it will only give execute permission to directories, not files.

edit: Actually X might give execute permissions to a file, but only if another user already has execute permission for it. In my given example this won’t happen since it removed all execute permissions just before.

1 Like

oh yeah didn’t notice you’re right :slight_smile: (actually didn’t even know the difference, never used it).
//EDIT: so in this case the execution bit on folders give right to application to write to files in subfolders if I understand?

Arch wiki has a page on file/directory permissions: File permissions and attributes - ArchWiki

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.