Keeping Filemote up to date

Every install checks for updates once at startup and then once a day. What happens next depends on the platform, because the two have genuinely different constraints: Windows has a window to ask you in, and a Linux server does not.

Windows: the configurator asks

On Windows the configurator owns updates and the agent deliberately stays quiet, so you never get two prompts or two installers running at once.

When a newer version exists you get a dialog with two choices:

  • Install downloads the release with a progress bar, then closes the application so the installer can replace files that are otherwise locked. The installer takes over from there.
  • Skip remembers that exact version and stops asking about it. A later version prompts again.

Linux and macOS: the agent does it

There is no window to ask in, so the agent downloads and applies updates by itself.

It will not interrupt you: while files are being transferred it logs transfers in progress — deferring to the next check and leaves the update for the next cycle.

Before anything is replaced, the agent checks there is enough free disk space and verifies the download's SHA-256. After replacing the binary it runs the new one with --version and compares what it reports; if that smoke test fails, the previous binary is put back and the update is abandoned.

When the install directory is root-owned

The agent runs as your user, but /opt/filemote belongs to root, so it cannot install there. It probes by actually trying to write a file — permission bits lie often enough on read-only mounts and in containers — and when the directory is not writable it downloads and verifies the update, unpacks it into /tmp/.filemote-update, and logs the single command that finishes the job:

sudo /opt/filemote/apply-update.sh /tmp/.filemote-update

That script stops the service, keeps the old binary until the new one passes its smoke test, rolls back if it does not, refreshes the AI service sources and starts the service again.

Archives up to and including 1.11.0 did not contain apply-update.sh, so on those installs the command above points at a file that is not there. Until you are on a newer build, update by re-running the install script from the new archive:

tar xzf filemote-<new-version>-linux-x64.tar.gz
cd filemote-<new-version>-linux-x64
sudo ./install.sh

Re-running the script preserves your settings and your downloaded models.

What an update replaces

Only two things: the agent binary and the AI service sources. The rule is an allow-list rather than a list of exclusions, so no future change to the archive layout can quietly start overwriting something else.

Never touched by an update:

  • app_settings.json — your login, paired token and shared folders
  • models — downloaded AI models, which are the expensive part
  • knowledge_base — everything you have indexed
  • the marker that records which Python dependencies are installed

The same guarantee holds on Windows for a different reason: an in-place upgrade never runs the uninstaller, so the private Python, the models and the settings all survive.

If the new version changed its Python requirements, the AI service notices and reinstalls them the next time AI starts.

Portable and ClickOnce

Turning it off

Set UpdateCheckEnabled to false in app_settings.json to stop checking altogether, or switch UpdateChannel between stable and beta. Both fields are described in configure the agent by hand.

Occasionally a release is marked as being below the supported floor. Those are logged as "install it as soon as possible" — usually a security fix — and are worth acting on even if you normally postpone updates.

Updated 2026-07-31

This didn’t help — contact support