The device shows as offline

Work down this list in order — the causes are roughly in order of how often they are the real one.

1. Is the agent actually running?

Installing the agent does not start it.

  • Windows: the configurator window is not the agent. Press Start in it, or check Task Manager for FilemoteAgent.exe.
  • Linux: sudo systemctl status filemote-agent. The install script enables the unit — so it survives reboots — but never starts it, so a fresh install reads inactive (dead) until you run sudo systemctl start filemote-agent.
  • macOS: launchctl list | grep com.filemote.agent. It starts at login, so it may simply not have started yet after installing.

2. Did the pairing settings reach the copy that is running?

This is the usual trap on Linux. Unless you tell it otherwise, FilemoteCli writes to app_settings.json beside its own executable, and it is not copied into the install prefix. So if you installed the service and then paired from the extracted archive folder, you configured a file the service never reads — and nothing reports an error, because from the service's point of view it simply has no credentials yet.

Point the configurator at the file the service uses:

sudo ./FilemoteCli --config /opt/filemote/app_settings.json
sudo systemctl restart filemote-agent

3. Can the agent reach the server?

The agent connects out to api.filemote.com on port 443. Check from the machine running the agent:

curl -sS -o /dev/null -w '%{http_code}\n' https://api.filemote.com/health

Anything other than a response means the agent cannot get out either — corporate proxies and restrictive outbound firewall rules are the usual reason. No inbound port forwarding is ever needed. If you changed the server address in the agent settings, set it back to Filemote's.

4. Was the device unlinked?

Removing a device from the device list in the file manager revokes its token, and it stops working immediately. If the device is gone from that list, pair it again with a fresh code.

Note that this is not the same as Sessions in your profile: those are browser sign-ins, and revoking one there does not unlink a device — nor does it fix one.

5. Has the pairing code expired?

Codes are single-use and expire 15 minutes after they are shown. A code that sat in a chat window overnight will not work; generate a new one.


The device is online, but folders fail with a JSON or "unexpected character" error

That means the agent connected fine and you are looking at a key problem, not a connection problem. The browser passes the raw error through, so the exact wording is whatever your browser says about invalid JSON — Chrome phrases it as Unexpected token …, "…" is not valid JSON. The agent's own log may instead report Unexpected character encountered while parsing value.

Your files are encrypted with a key derived from your account password (PBKDF2-SHA-256 over the password and a salt tied to your account). The server never sees that key — which is the point — but it also means the key exists in two places: your browser and the running agent.

Change your password and the browser derives the new key immediately, while an agent that is already running keeps the old one. Everything it sends back then decrypts to garbage, and the first thing that trips over it is JSON.parse, which is why the error mentions parsing rather than decryption.

Fix: restart the agent, then sign in again in the browser so both sides derive the key from the same password. If you changed your password recently and several devices went strange at once, this is why.

Updated 2026-10-16

This didn’t help — contact support