Where to set XDG_CACHE_HOME?

Marek Greško marek.gresko at protonmail.com
Sat Feb 28 17:29:46 GMT 2026


Hello,

using symlinks is not an option here, since the use could use any machine in the network and some of them do not have local storage. I set the environment for the users only on the machines with the local storage.

Regarding bind mount, I think it is not feasible to maintain fstab for the whole list of users on all the machines. This would be a major headache.

Thanks for suggestions.

Marek




Odoslané pomocou bezpečného emailu Proton Mail.

sobota 28. februára 2026, 15:27, René J.V. Bertin <rjvbertin at gmail.com> napísal/a:

> On Saturday February 28 2026 10:54:53 Marek Greško wrote:
> 
> >Do you have any clue where should be the script run from to be started soon enough I do not have the $HOME/.cache/mesa_shader_cache created?
> 
> Could you do a "bind mount" of ${CACHEDIR}/.cache onto ${HOME}/.cache ?
> 
> I have a comparable set-up where home dirs are on a "safe" ZFS dataset (copies=2 or a pool with mirrored vdevs) but I don't want the costly safety for cache directories. Rather than giving each user a dedicated dataset for that, I have a single one with a directory structure that gives each user a .cache directory. The bind mounts are defined in /etc/fstab, and triggered via /etc/rc.local once I'm certain all datasets have been mounted.
> 
> You could probably also just make each ${HOME}/.cache a symlink to your local target location. I've done that for a long time, and the only advantage of bind mounts is that normalised (aka canonical) paths (as obtained e.g. via `realpath`) will still be of the form ${HOME}/.cache . The advantage of symlinks is that you only set them up once without having to modify system scripts/tables on each machine where the users might log in. You'd be relying on users not replacing the symlink ... but if they do it's mostly their problem, no? ;)
> 
> In either case, you may run into problems with applications that e.g. download something to the cache area, and then "move" it into place with system calls like rename(2) that don't do cross-mount operations. I've seen both Chromium and Firefox fail to install/update extensions because of this kind of situation they hadn't foreseen (though it was probably not related to the cache area).
> 


More information about the kde mailing list