SystemdDoctor
служба не работает синхронизация окружение изоляция

Служба синхронизации файлов работает не с тем каталогом

Службы, хранящие настройки в домашнем каталоге, зависят от того, каким этот каталог видит процесс. У системной службы он может отличаться от каталога пользователя, а изоляция unit-файла способна подменить его вовсе. Итог — служба работает с пустыми настройками.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Домашний каталог процесса не тот, что у пользователя

    Системная служба получает домашний каталог из записи пользователя, но параметры unit-файла могут его переопределить.

  2. Защита домашних каталогов скрывает настройки

    Параметр защиты домашних каталогов делает их пустыми или недоступными для процессов службы.

  3. Служба запущена и в системной, и в пользовательской области

    Два экземпляра с разными каталогами настроек дают расходящиеся списки папок и непредсказуемую синхронизацию.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Пользователь, окружение и изоляция службы.

systemctl show syncthing@user -p User -p Environment -p ProtectHome 2>/dev/null

Где лежат настройки службы.

sudo ls -l /home/user/.local/state/syncthing 2>/dev/null

Какой каталог настроек служба сообщает при запуске.

journalctl -u "syncthing@*" -n 20 --no-pager

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Домашний каталог процесса не тот, что у пользователя
Почему происходит
Системная служба получает домашний каталог из записи пользователя, но параметры unit-файла могут его переопределить.
Как проверить
Посмотрите, какой каталог видит процесс службы. 
systemctl show syncthing@user -p User -p Environment -p WorkingDirectory 2>/dev/null
sudo systemd-run -q --pipe --property=User=user sh -c 'echo $HOME' 2>/dev/null
Как исправить
Задайте каталог настроек службе явно параметром командной строки или переменной окружения, не полагаясь на домашний каталог.
2. Защита домашних каталогов скрывает настройки
Почему происходит
Параметр защиты домашних каталогов делает их пустыми или недоступными для процессов службы.
Как проверить
Посмотрите параметры изоляции. 
systemctl show syncthing@user -p ProtectHome -p PrivateTmp -p ReadWritePaths 2>/dev/null
Как исправить
Отключите защиту домашних каталогов для этой службы или перенесите настройки в каталог состояния и разрешите к нему запись. 
[Service]
ProtectHome=no
StateDirectory=syncthing
3. Служба запущена и в системной, и в пользовательской области
Почему происходит
Два экземпляра с разными каталогами настроек дают расходящиеся списки папок и непредсказуемую синхронизацию.
Как проверить
Посмотрите оба места. 
systemctl is-active "syncthing@*" 2>/dev/null; systemctl --user is-active syncthing 2>/dev/null
Как исправить
Оставьте один экземпляр. Для службы одного пользователя пользовательская область подходит лучше, но требует продолжения работы без входа.

Пример вывода

Служба видит не тот домашний каталог. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

syncthing[8000]: INFO: syncthing v1.27.0 starting
syncthing[8000]: INFO: Generating ECDSA key and certificate for syncthing...
syncthing[8000]: INFO: My ID: A1B2C3D-...
# новый идентификатор при каждом запуске: настройки создаются заново

Связанные ошибки

Источники

  • systemd.exec(5)
    ProtectHome=, StateDirectory= и домашний каталог процессов службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено защитой домашних каталогов при службе с настройками в домашнем каталоге.     собственная проверка, systemd 255
    сверено 15 сентября 2026