Syncthing stops every day or so. Does not autorestart.


Hello, I’ve been running ST a year and a half on 5 machines. One is a headless ubuntu 16.04 server where I start ST by typing “sudo systemctl start syncthing@doreen.service” after I log in via SSH after start-up and unlock my encrypted home folder. It used to run fine for weeks at a time, but recently it stops running after a day or so. No processes visible with htop. I log in, type the command above and it then runs for another day or two.

It runs fine on my other machines.

Any ideas why it might be doing this on my server?

Much appreciated.


(Audrius Butkevicius) #2

Check the logs.

(Jakob Borg) #3

You log in to

which then presumably locks itself and goes away when you log out. At which point Syncthing doesn’t have a config or database any more and gets rather unhappy.

(That’s how encrypted homes work in several distros at least - if my assumption is incorrect, do what Audrius suggests. :slight_smile: )


That sounds like a reasonable explanation. Extract from a long syslog file:

10 hours of: Sep 5 06:26:09 djp-server syncthing[21618]: [7DCRP] INFO: Skipping pull of “Sync-work” (Sync-work) due to folder error: folder path missing …

Then suddenly: Sep 5 19:07:14 djp-server syncthing[21618]: [7DCRP] INFO: Connection to BSZPK2X-HIPOGQP-UDE2KLW-ZWTNIYS-PFRXGIM-WHDRWDK-R3UUO2I-IIEIYAX closed: Sep 5 19:07:14 djp-server syncthing[21618]: panic: open /home/doreen/.config/syncthing/index-v0.14.0.db/013043.log: no such file or directory Sep 5 19:07:14 djp-server syncthing[21618]: #011panic: runtime error: invalid memory address or nil pointer dereference Sep 5 19:07:14 djp-server syncthing[21618]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x93c05f] Sep 5 19:07:14 djp-server syncthing[21618]: goroutine 4185 [running]: S

and a lot more stuff that seems to say it can’t restart as it can’t find the folder paths or config files.

If so, then the problem seems to be on the Ubuntu side - why it does not stay logged into the encrypted homefolder. So not Syncthing!

Thanks very much for your rapid comments,



This Ask Ubuntu link seems to say that under systemd, the unmounting of .ecryptfs doesn’t work and that the folders remain accessible. So I have maybe been running ST dependent on this bug (logout via SSH, but the folder paths remain accessible…for a day or two until it finally unmounts).


For anyone searching the forum in the future, the solution is detailed here.

Briefly, if you want to run Syncthing with its target folders lcoated inside your encrypted home folder, then delete or rename ~/.ecryptfs/auto-umount.

After logging out of the server via SSH, the home folder remains mounted so ST can continue its work.


(system) #7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.