NFS for Desktops, Syncthing for Laptops

I have two kinds of Linux machine at home: desktops that are always connected to the network, and laptops that are not. That distinction drives everything about how home directories work.

Desktops: NFS, transparently Link to heading

On desktops, /home is the NFS mount. There is no local home directory: the server’s storage is the home directory. Log in and your files are there. No sync, no waiting, no copies to reconcile. The mount happens over Tailscale, so it works from anywhere on the tailnet, not just on the local network.

The tradeoff is real: if the network is unavailable, you cannot log in. For a desktop that is always connected, that is an acceptable constraint.

Laptops: Syncthing, resiliently Link to heading

Laptops have a local home directory. Syncthing keeps it in sync with the server copy and with other laptops when both are online. Disconnect from the network, travel, work offline: your files are there. Reconnect, and changes propagate.

The asymmetry is intentional.

A desktop that cannot reach the network is broken anyway. A laptop that cannot reach the network is normal use.

The XDG problem Link to heading

A shared home directory immediately runs into a problem that has nothing to do with the files you want to share. It is the files you do not: .config/application/prefs, .local/share/recently-used, PulseAudio state, browser profiles, app caches. These are machine-specific. Share them across machines and things break in subtle ways: the wrong display settings, the wrong audio device, cache files from a different architecture.

The problem with a shared home directory is not the files you want to share. It is the files you do not.

The solution, inspired by this post, is a two-level symlink chain:

~/.local   →  /local/$USER/.local   →  ~/.xdg/<hostname>/.local/
~/.config  →  /local/$USER/.config  →  ~/.xdg/<hostname>/.config/

/local/$USER/ serves two purposes. For caches, browser profiles, and build artefacts (things that are large, recreatable, or performance-sensitive), it is genuine local storage that stays on the machine. For .config and .local it is just an intermediate hop: the chain continues back into the home directory under a per-hostname subdirectory, so the config data stays in the shared home.

The result: each machine has its own .config and .local, stored under its hostname in the shared home. On desktops those per-hostname directories live on NFS, visible from any machine. On laptops they live locally and sync via Syncthing.

Unlike the original approach, which moves config entirely off the shared home and strands it on local disk, this keeps each machine’s config in the shared home: isolated per machine, but backed up with everything else.

What this gives you Link to heading

A new machine joins the network. After installing the right metapackage, the home directory appears and files are there. Applications start with sensible defaults, not another machine’s state.

A laptop goes offline for a week. It works. When it reconnects, Syncthing reconciles the changes.

A desktop mounts a consistent home directory from any point on the tailnet. There is one copy of the files and every desktop sees it.

The per-hostname XDG directories mean that each machine’s state is preserved in the shared home, visible if you need it. The chaos of a naive shared home, where apps fight over the same config directory from different machines, does not happen.