"Locations - System Settings" not persisting after power cycle. Do I need a delay between automounting drives and spawning KDE?

After applying changes to my default paths, which are on another drive, and a power cycle, the locations to all those custom paths have defaulted to /home/username/

I never want those paths to default automatically. but maybe it’s ok if I inserted a delay before the desktop environment paths are created. I have the drives automount at login, but I am afraid that isn’t fast enough. Either that or my paths aren’t persisting due to setting them without being a sudoer.

am i right or?

Disable the user service

Not necessary

More the or :slight_smile:

You are using KDE and I remember the issue has been discussed some time ago.

The folders is read by xdg and is stored in ~/.config/user-dirs.dirs - so editing that file will override what is set for the locale.

➜  ~ cat .config/user-dirs.dirs 
# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.

My personal approach is to convert the folders in $HOME to symlinks e.g.

rm ~/Documents
ln -s /path/to/documents ~/Documents

I have been using such setup for years with no issues.


cool, thanks for that.

I wonder though, if the “Locations — System Settings” routine is supposed to be for creating any location you want for Desktop, Documents, Downloads, Videos, Pictures and Music, then why doesn’t it retain the data I type into those fields and apply them? I read the link and I didn’t see an explanation. I think what’s happening is that the drives are being mounted after the custom directories are being read, and if so then I see it as unexpected behavior unless that is on some to-do list to put those actions in the right order: 1) mount drives 2) check for the existence specified folder locations otherwise default them.

What’s your theory on the issue from the perspective of expected behavior of the “locations system services” paths dialog? Can I still use the beautiful “locations — system settings” dialog window if I zero the sdg-user-dirs-update bool? If this is “just the way Manjaro is” then perhaps there can be a note that says you can’t use custom paths that are on another drive than the system one, which does seem weird.

I think “mount drives at login” isn’t soon enough. I suspect that the directories are already made before login has happened. What needs to happen is that drives need to be mounted before KDE is spawned for KDE to find the folders in other drives. That’s at least my theory.

but maybe it’s a security issue. if so, then there needs to be a delay after login and drive auto-mounts, and then run the bit of code that checks if paths exist after a few hundred milliseconds has elapsed.

Persistent mountpoints - I assume this is what you have created - and is what you need - are mounted before login.

The xdg user-dir service is run as a the user logging in - which in turn will create the folders using the locale defined in ~/.config/user-dirs.locale so you are barking up the wrong tree.

I am not a KDE user but within KDE I think the location defined in system settings is created for the exact purpose you are intending - but I have no knowledge of how KDE works - I only know that they stray a lot in their quest to make everything super customizable and that includes adding non-system locales.

I think the real issue may be the locations is pointing to a device which is not made available using either fstab or a mount unit.

If your location setting is pointing to a mount in /run/media/$USER tree you should know this is a volatile structure which is recreated on user login and then your targets does not exist which will lead to the folders to being recreated by the xdg user-dir service.

1 Like

As that answered your primary question, I’ve marked this answer as the solution to your question as it is by far the best answer you’ll get.

However, if you disagree with my choice, please feel free to take any other answer as the solution to your question or even remove the solution altogether: You are in control! (If you disagree with my choice, just send me a personal message and explain why I shouldn’t have done this or :heart: or :+1: if you agree)

P.S. In the future, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:
so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

1 Like

Hi, thanks for your service. If you’d like to interpret it that way then that’s fine, since this issue is open to interpretation and personal preference (like setting up an automount in fstab vs the more volatile ‘at login’ automount method). I don’t have a preference myself since I am still establishing a periphery of understanding the Manjaro distribution as well as Arch, and of course, the intricacies of the Linux Way.

I’ve emailed part of the KDE team about it so at least the documentation for that particular KDE Locations module I mentioned could be updated, since it was out of date.

1 Like

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