Detect failed Borg FUSE mounts before dependent file jobs run

Gate dependent file jobs on verified Borg mount health and retained diagnostics.

Source facts

Borg 1.4.5 mount normally daemonizes, and a daemon signal or crash does not automatically unmount the filesystem. The documentation explains that automatic unmounting could expose an underlying empty directory to a running synchronization tool and lead to unintended deletion. In foreground mode, an interrupt signal cleanly unmounts, but other signals and crashes do not. Daemon output normally goes to the null device, so foreground execution or explicit logging configuration is needed when diagnosing mount failures.

Source: Borg 1.4.5 — borg mount.

Applicability

This applies to Borg 1.4.5 FUSE mount supervision. It concerns dependent file jobs and failure visibility, not a claim that a mounted archive has passed a complete recovery test.

DSE recommendation

DSE recommends making mount health an explicit prerequisite for any dependent comparison, copy, or synchronization job. Keep a harmless expected marker inside the selected archive and require its presence before a destructive downstream operation is considered. Preserve diagnostic output through the intended service logging arrangement. Have the operator distinguish an unavailable FUSE mount from an ordinary empty source directory, and document a controlled stop procedure for downstream work when the mount becomes uncertain.

Verification

Rehearse mount interruption with disposable archives and a harmless downstream job that only reports its intended actions. Confirm the health gate prevents further work after failure and that logs explain the cause. Test orderly unmount separately and verify the expected mountpoint state before restarting dependent tasks.

Official reference

Borg 1.4.5 — borg mount. Reviewed October 15, 2026.