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 <[email protected]> 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). >
