Accepted Limitations of Offline Secondary Storage (Linux)

Messages in secondary storage are not lost just because a secondary storage directory is offline. As long as the secondary directory is unreachable, the message will not be viewable and cannot be synced to clients, or otherwise acted upon by SmarterMail, but the messages should be reachable once secondary storage comes back online. This includes when our cleanup routines run: if the drive is unavailable, nothing is touched.

There are some additional conditions that are currently only enforced on Linux, and that is that a secondary storage path is not permitted to just be on the primary filesystem drive. This is because logic for detecting if the secondary storage path is online needs to be able to distinguish between an online mounted drive and an unmounted or offline drive, and there is no way to distinguish between an unmounted/offline drive and a directory that is actually stored on the primary filesystem drive.

As such, there are some known, and accepted, limitations of the protections SmarterMail has in place when dealing with offline/unavailable secondary storage in Linux:

Enable-time restriction (Linux, new behavior): a secondary storage path on the operating system's root filesystem is now rejected when enabling secondary storage. The path must live on its own mounted volume, because an unmounted mount point is indistinguishable from a plain local directory.

Marker file self-heal vs. pre-upgrade underlay junk: Linux backs each mount with a directory on the primary filesystem drive. If the mount is not actively mounted, Linux will serve up the backing directory without any warning. This can pose a complication for the new reachability probe, which treats a root with contents but no .sm_secondary_root marker as a live volume and stamps the marker (upgrade path for existing installs). If anything ever wrote into the underlying directory of an unmounted mount point during an outage, that junk makes the underlay look live until the real volume is mounted over it — at which point the marker is hidden and the probe fails closed. The best fix for this is to delete the contents of backing directory.

Empty root with a missing marker reads as offline: if the marker is lost on a genuinely healthy but empty volume (e.g. mounted over its enable-time marker), the probe reports the volume unreachable until the marker file is manually re-created. If this situation is encountered, it will be properly logged. The fix is to add any content to the mounted directory, though preferably either a Users directory or a .sm_secondary_root file.

Symlinked paths are not canonicalized against the mount table: the enable-time mount check is best-effort; the marker file is the runtime guard.

Deferred rebuild retries are in-memory: a rebuild deferred because secondary storage was unreachable is retried by the save loop, but the retry queue does not survive a service restart. The rebuild re-triggers on the next mailbox load, since the deferral never overwrites the CFG.