LMDE7 x 2, OMV8 x 1 (or Deb x 3) v2.1.0, Linux (64-bit Intel/AMD)
On all three machines reboot seems to reset everything in ~/.local/state/syncthing to a new state with a new ID, no shares, no password on GUI, non multi gig database, everything reset.
At first I thought it must be a permissions problem but another kernel update came through today and it happened again, on two machines and I haven’t rebooted the other.
Any ideas?
Docker, volumes, not properly mounted?
No. Apt installs from the apt.syncthing stable repo.
Any other files disappearing from the same home directories?
Syncthing has no code in it for deleting the config dir. It must be some other component clearing out the home directories.
No, but luckily I have a server upstairs also running it that I hadn’t updated. Just tested it now and it’s weird. I kept notes.
At this point the server is running syncthing fine with all shares up to date.
User
cp -Rv ~/.local/state/syncthing ~/.local/state/syncthing/backup
Root
sudo apt update && sudo apt upgrade
(which installs linux-base-amd64 linux-image-amd64 openmediavault)
Browser(Server GUI has 0.0.0.0 access):
Check syncthing in gui and restart syncthing to check whether alteration has already happened.
Syncthing fine.
Root
Reboot system
System fails to restart. Manual restart.
systemctl status syncthing@.service
Status fine.
Browser
No access
User
du -hs .local/state/syncthing && du -hs .local/state/syncthing_backup
Same size
Check config file and all is the same.
Root
systemctl restart syncthing@.service
systemctl status syncthing@.service
Status good
Browser
Access. It appears the config.xml has been read and all is normal.
Thoughts
All these computers are running with separate home drives to the root drive
Drive 1 - /
Drive 2 - /home
So is it possible syncthing is starting before the home drives are mounted, using a fallback profile from elsewhere and not reading the config.xml in ~/.local/state/syncthing until restart?
Are you sure that your use of the systemctl commands is correct? The syncthing@.service syntax addresses a template. You need to instantiate that by appending an actual user name after the @ sign. If you don’t, I suspect it might be using the calling user name instead, which is different when run by root or the normal user. Consequently, two different instances are involved, with different home directories. Better check with ps axu | grep syncthing which Syncthing processes are actually running and owned by which user.
Seems fine with all processes being owned by the proper user except for one on the server.
Edit: @acolomb The reason the commands didn’t look right was because I added them in between brackets.
OK, I reset comp1 to the 13/05/2026 using time shift and went through the process again. Same thing happens.
Feel free to post output directly here instead of that ad-polluted platform.
Can you please post the exact command you used for systemctl status ... and the related output, both before and after the restart which seems to fix it?
Currently it looks to me as if the instance you want to be running automatically is not actually started. Therefore no GUI, no log file. I don’t understand how you can assume “new ID” when neither is available? What makes you believe there is even a Syncthing instance running? Where does it advertise a “new ID”?
The fact that the syncthing.lock file appears only after the restart strongly indicates that whatever is running on that host initially is not a Syncthing instance using this home directory for its state. After you “restart” it, the desired service seems to come up for the first time.
Your separately mounted home drive may be part of the problem. If you cannot verify through systemd tooling that the service unit is started only after the home drive has been successfully mounted, then you could add an explicit ordering directive (After = whatever.mount) to the unit using an override file (sudo systemctl edit syncthing@bluefountain.service).
This seems to be more of a systemd issue, so try to get a grip on the provided diagnostic commands and unit structure. Especially template units.
I did not find one listed for the forum.
The exact command is,
sudo systemctl status syncthing@bluefountain.service
It is running because I, checked the process status (as above) and ownership (using your suggestion) and then opened the browser at 127.0.0.1:8384 where it served the page you get when you have installed syncthing for the first time. The new ID is on that page.
Ok, then sorry I must have misunderstood your description in the first post (Browser: no access).
So it does sound a lot like the service is running before the real home dir becomes available. My recommendations about systemd above still apply.
One more thought how to easily mitigate this, except the systemd ordering directives. You can run it as a user service as well, not a templated system service. Using loginctl enable-linger ... you can even still make it start in boot without waiting for a login. No sudo required anymore.