Automatic Updates

The mount client includes a built-in automatic update mechanism that downloads new versions from the admin server and performs a live FUSE session handoff, allowing updates without unmounting the filesystem or interrupting running applications.

How it works

1. Periodic check — The daemon polls the admin server’s deploy endpoint at a regular interval (default: every 360 seconds / 6 minutes) to check for a newer version.
2. Download — When a newer version is available, the client downloads the new binary next to the installed one and verifies that it runs and reports the published version, then replaces the installed binary in a single step. A download that fails this check is discarded and the installed binary is left untouched.
3. FUSE session yield — The running mount client pauses serving the mount, writes out any pending data, and passes the active FUSE session and its open file state to the new binary.
4. Handoff — The new binary adopts the yielded FUSE session, inheriting the mount point and all open files. The old process exits once the new one is serving.
5. Transparent — Applications reading and writing to the mount point experience no interruption. The mount never disappears from the mount table.

Update channels

FlexFS supports two update channels:

• Production (default) — Stable releases deployed to the admin server’s production deploy folder.
• Staging — Pre-release builds deployed to the staging folder. Enabled with --staging.

The deploy endpoint is derived from the admin server address:

• Production: https://<adminAddr>/deploy/production
• Staging: https://<adminAddr>/deploy/staging

Controlling updates

Flag	Effect
--noRemount	Download and install the update, but do not perform the FUSE session handoff. The running mount keeps serving with the old binary until it is next restarted. Automatically implied by --foreground.
--noUpdate	Disable automatic updates entirely. The mount client will not check for or install updates. Implies --noRemount.
--staging	Check the staging channel instead of production.

See the mount.flexfs CLI reference for the authoritative entries, including types and defaults.

Foreground mode

When running in foreground mode (--foreground), --noRemount is automatically implied. In this configuration, the mount client downloads the new binary but does not attempt the FUSE session handoff. Mounts running under systemd (without --foreground) are not affected — they perform the normal session handoff.

Note

Auto-update is disabled when the build version has a major version of 0 (development builds), and when the user running the mount cannot write both the binary and its folder (for example, a non-root mount of the root-owned /sbin/mount.flexfs installed by the mount client installer script).

Manual updates

For environments where automatic updates are disabled, download the latest mount client from the admin server, then remount each flexFS mount so it runs the new binary:

sudo curl -fksSL https://<admin-addr>/deploy/production/v1.9.x/linux/amd64/mount.flexfs -o /sbin/mount.flexfs.new
sudo chmod 755 /sbin/mount.flexfs.new
sudo mv -f /sbin/mount.flexfs.new /sbin/mount.flexfs
sudo umount /mnt/flexfs && sudo mount /mnt/flexfs

Use arm64 in place of amd64 on ARM hosts, and staging in place of production for mounts started with --staging. Remounting with mount requires an /etc/fstab entry; restart other mounts with the mount.flexfs start command that created them. Downloading to a separate file and renaming it replaces the binary safely while mounts are running it. Mounts keep running the previous binary until they are remounted, and a mount that is in use cannot be unmounted until the processes using it exit.

To make a new mount client available to auto-updating mounts, deploy it on the admin server host:

sudo manage.flexfs deploy --version v1.9.x

During the handoff

1. The old process stops accepting new filesystem requests and finishes writing out pending data. Requests issued in the meantime wait and are answered after the handoff.
2. The new process adopts the FUSE session and starts serving it.
3. The old process exits once the new process reports that it is serving.

Only one process serves the mount at any time. If the new process exits before it starts serving, the old process resumes serving the same mount, so applications see a short pause rather than an error. The failure is logged, and the old process waits an hour before trying that version again; a newer version is tried at the next update check.

A handoff is postponed while an application on the mount is waiting for a blocking file lock (fcntl(F_SETLKW) or flock), and is retried at the next update check.

A shutdown signal received during the handoff takes effect once the handoff ends; further signals in the meantime are logged and do not interrupt it. A mount that is in use at that point cannot be unmounted, so it keeps serving and a later shutdown signal is accepted.