Пристрій показано як офлайн
Ідіть за списком по порядку — причини розставлені приблизно за тим, наскільки часто вони виявляються справжніми.
1. Агент узагалі запущено?
Встановлення агента не запускає його.
- Windows: вікно конфігуратора — це не агент. Натисніть у ньому Start або
перевірте в диспетчері задач наявність
FilemoteAgent.exe. - Linux:
sudo systemctl status filemote-agent. Скрипт встановлення вмикає юніт — щоб той переживав перезавантаження, — але ніколи його не запускає, тому свіже встановлення показуєinactive (dead), доки ви не виконаєтеsudo systemctl start filemote-agent. - macOS:
launchctl list | grep com.filemote.agent. Він стартує під час входу в систему, тому після встановлення міг просто ще не запуститися.
2. Чи дійшли налаштування підключення до тієї копії, яка працює?
Це звична пастка в Linux. Якщо не сказати інакше, FilemoteCli пише app_settings.json
поруч зі своїм власним виконуваним файлом, а в префікс встановлення він не копіюється.
Тому, встановивши службу й виконавши підключення з теки розпакованого архіву, ви налаштували
файл, який служба ніколи не читає, — і ніде немає помилки, бо з погляду служби вона просто
ще не має облікових даних.
Вкажіть конфігуратору той файл, яким користується служба:
sudo ./FilemoteCli --config /opt/filemote/app_settings.json
sudo systemctl restart filemote-agent
3. Чи може агент достукатися до сервера?
Агент підключається до api.filemote.com через порт 443. Перевірте з машини, де він працює:
curl -sS -o /dev/null -w '%{http_code}\n' https://api.filemote.com/health
Усе, крім відповіді, означає, що агент теж назовні не вибереться, — звична причина — корпоративні проксі та суворі правила вихідного трафіку на файрволі. Пробрасувати вхідні порти не потрібно ніколи. Якщо ви змінювали адресу сервера в налаштуваннях агента, поверніть адресу Filemote.
4. Чи не було пристрій відв'язано?
Видалення пристрою зі списку пристроїв у файловому менеджері відкликає його токен, і він перестає працювати негайно. Якщо пристрою в цьому списку немає, пов'яжіть його заново новим кодом.
Зверніть увагу: це не те саме, що Сесії у вашому профілі — там перелічені входи з браузера, і відкликання одного з них не відв'язує пристрій, але й не лагодить його.
5. Чи не сплив код підключення?
Коди одноразові і спливають через 15 хвилин після показу. Код, що пролежав ніч у вікні месенджера, не спрацює; згенеруйте новий.
Пристрій у мережі, але теки падають із помилкою JSON або «unexpected character»
Це означає, що агент підключився нормально і перед вами проблема з ключем, а не зі
з'єднанням. Браузер пробрасує вихідну помилку як є, тому точне формулювання — це те, що ваш
браузер каже про некоректний JSON: Chrome формулює це як
Unexpected token …, "…" is not valid JSON. У журналі самого агента може бути інше:
Unexpected character encountered while parsing value.
Ваші файли шифруються ключем, виведеним із пароля вашого облікового запису (PBKDF2-SHA-256 за паролем і сіллю, прив'язаною до вашого облікового запису). Сервер цього ключа ніколи не бачить — у цьому й суть, — але це ж означає, що ключ існує у двох місцях: у вашому браузері та в робочому агенті.
Змініть пароль — і браузер одразу виведе новий ключ, а вже робочий агент збереже старий.
Усе, що він надсилає назад, розшифрується в сміття, і першим на цьому спотикається
JSON.parse — тому в помилці й ідеться про розбір, а не про розшифрування.
Як полагодити: перезапустіть агента, потім увійдіть у браузері заново, щоб обидві сторони вивели ключ з одного й того самого пароля. Якщо ви нещодавно міняли пароль і одразу кілька пристроїв повелися дивно, причина в цьому.
Оновлено 2026-10-16