Root cause of the recurring nas_audiobooks ESTALE flapping (18 remounts in
82min on 9/15, 13+ continuous through several hours on 9/17): the mount
sat behind mnt-nas_audiobooks.automount instead of a permanent .mount unit,
exactly matching this doc's own pre-existing "Docker bind mounts + automount
= stale handles" gotcha. Switched to systemd enable --now on the .mount
unit directly (matching nas_family/nas_books/nas_owncloud), removed the
automount unit. Confirmed stable after the change - self-heal script no
longer needed as anything but a backstop for this share.
Host reboot broke the nas_media Docker NFS volume for 6+ hours (plex,
qbittorrent x3, navidrome, sonarr, jellyfin all down): nfs-utils 2.6.4 no
longer accepts the ":/path" + addr= device split, and separately Docker's
local volume driver can't do nfsvers=4 (calls mount(2) directly, skipping
the mount.nfs helper's version negotiation). Volume recreated with an
explicit host:/path device and vers=3. Updating docs/comments to match
the corrected live config so the next person doesn't recreate the same
broken volume from the stale example.
Stale NFS handles inside containers (ESTALE/errno -116) can persist even
after the host-side mount looks healthy, requiring a manual remount +
container restart. Adds systemd mount-ready hooks (BindsTo) to restart
immich_server/calibre/ocis when their NFS mount unit restarts, plus a
5-minute health-check timer that does a real nested read and force-remounts
on staleness. Host files backed up under system-config/nfs-self-heal/ so
they can be reinstalled after a host rebuild.
poprhythm