Some KDE setting are not saved upon system restart

[arslancharyev31]

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?

[omano]

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

[bogdancovaciu]

After this discussion

Global Shorcuts are messed up after the latest update

Hello there. After updating my installation to the latest version (20.1), my Launch Konsole shortcut (Ctrl+Alt+T) stopped working. Swtiching to Defaults removes this and some other shortcuts altogether. Importing a scheme has no effect whatsoever. I tried binding a shorcut directly to Konsole application as well (as opposed to the KDE Daemon -> Launch Konsole) with no success. I don’t know where to start troubleshooting this issue and I would appreaciate any help.

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

[arslancharyev31]

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.

[freggel.doe]

@arslancharyev31

my config files lost the rw permissions after the update

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

@arslancharyev31

setting 666

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

[arslancharyev31]

@freggel.doe

only the owner needs rw .

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.

[freggel.doe]

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

[omano]

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
/home/omano/.config/plasma-org.kde.plasma.desktop-appletsrc
/home/omano/.config/pipewire-media-session/default-routes
/home/omano/.config/pipewire-media-session/default-profile

[freggel.doe]

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.

[omano]

oh yeah didn’t notice you’re right (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?

[freggel.doe]

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