What exactly does changing path in Locations do?

In System Settings > Applications > Locations I can change the default path of folders like Desktop, Documents, Downloads, etc…

What exactly does that do?

I’m wondering if I could use it for something.

I want my /home to stay on the disk/partition it is but I want SOME of my folders to be on another disk/partition. Something like:

  • /home/me/Downloads = default place
  • /home/me/Documents = /data/me/docs
  • /home/me/Music = /data/music

My initial/gut thought was to use symlinks. So /home/me/Documents would be a symlink that points to /data/me/docs.

But then I saw the Locations setting and am wondering if maybe that is a better way to do this.

Yep, if you want applications that show you a “Documents” or “Pictures” folder to look elsewhere other than /home/yourusername/Documents, /home/yourusername/Pictures, etc., that place you found in the Settings would be the way to go.

Using that won’t modify anything in the actual filesystem about those folders, but it will direct the “Places” identified as Documents, Downloads, Pictures, etc. to the folders that you specify, instead. The underlying mechanism there is defined in the FreeDesktop spec for xdg-user-dirs:


The path /mnt/T3/Music means that my 3GiB of Music is in the ‘default’ location, and that location is NOT on my SSD, it’s on my HDD. The same goes for media (Video) which is a 4TB collection, and I only use a 250GiB SSD for my install :wink:


Got it.

So then it won’t create “links” such that, from the command line, /home/me/Documents points to /data/me/docs. I would have to create those links myself. Right?

@ben2talk Got it. Thanks!

1 Like

That’s right - it’s not changing how your actual underlying file system is structured, it’s changing the location in that filesystem where applications (ones that support freedesktop.org / xdg standards) will look by default for those things.

So for example, if an app is going to download a file to your local storage, instead of hard-coding $HOME/Downloads - which would need to be translated anyway for non-English setups, and wouldn’t be right for every configuration - it can direct the file to $XDG_DOWNLOAD_DIR, which will point to the right/intended filesystem location.

That also enables access to those locations to be controlled via portals - e.g. a Flatpak application can specify in its manifest that it needs read/write access to your Downloads folder, and then the xdg-desktop-portal will expose $XDG_DOWNLOAD_DIR to the Flatpak container.

Caveat: I have zero development experience with any of this, just a user who has poked around on his own system and reads a lot of things written by people smarter than I am, so if anyone sees something missing or backwards here please correct!

1 Like

I do this with bind mounts. In /etc/fstab:

# Bind mounts:
/mnt/data/Pictures                  /home/john/Pictures   none      bind    0 0
/mnt/data/music                     /home/john/music      none      bind    0 0

/home/john/music is the “logical” path to the directory, but it is physically on the /mnt/data partition.

Dang you for throwing one more viable option at me.

Using bind mounts seems to provide a more complete solution because every application would be oblivious to this and would just use the normal paths it knows like $HOME/Downloads.

Any cons with using bind mounts?