Synology Syncthing 2.0 doesn't start

nik684 · March 5, 2026, 12:11pm

Hello, support. I’m a long term user of Syncthing on my local Synology 216j NAS. In Feb I updated it to v2 without any issues.

A couple of days ago I saw usual update button on the top (I don’t remember the version though, I think it was 2.0.15) and clicked on it. It’s strange, because the latest build in SynoCommunity is 2.0.13-33.

Next morning syncthing stopped working on my nas completely. It just doesn’t start at all. When I click “Run” in Package Center it creates Syncthing icon on the synology OS desktop and in a couple of seconds it kills it and stops the app (it looks like a crash or sth like that).

Clean reinstall didn’t help. I even tried to find some leftover files via SSH and cleaned those as well.

I’m not sure if this will help but here is the content of syncthing.log file

calmh · March 5, 2026, 1:34pm

There’s an incompatibility between the Synology kernel and the Go version Syncthing is currently built with. The Go project are working on a workaround for a point release.

SquiIIiam · March 6, 2026, 8:45pm

Been losing my mind over this issue for the past few days, thanks for the explanation. Where can I follow progress on this workaround?

Nummer378 · March 7, 2026, 9:38am

github.com/golang/go

runtime: regression Synology's Linux fork of linux causes syscall conflict on older kernel versions

opened 07:20AM - 04 Mar 26 UTC

Jorropo

NeedsFix compiler/runtime FixPending BugReport

@calmh [report](https://github.com/golang/go/issues/77730#issuecomment-399366264…7): We seem to be seeing the same crash on armv7 -- or should I file this separately? https://github.com/syncthing/syncthing/issues/10587 The return code is slightly different: ``` $ syncthing --version futexwakeup addr=0x4458b24 returned -22 16:54:03 [49/305] SIGSEGV: segmentation violation PC=0xc7f02c m=0 sigcode=1 addr=0x1006 ``` @Rongronggg9 [explains](https://github.com/golang/go/issues/77730#issuecomment-3995018983): No, these crashes on armv7 are completely different. Arm is an arch that uses `include/uapi/asm-generic/errno.h`. The root cause lies in Synology's ancient kernel. They had a faithful belief that they were cleverer than upstream kernel developers and added vendor (!) syscalls to their kernel. Not only did they add vendor syscalls, but they also forgot to leave enough reserved space to avoid conflict with the newly introduced syscall numbers of the upstream kernel. This is literally the most cursed thing you've ever seen in the Linux world. They should really have used ioctl or so... ```asm CALL(sys_SYNOUtime) /* 402 */ CALL(sys_SYNOArchiveBit) /* 403 */ CALL(sys_recvfile) /* 404 */ CALL(sys_SYNOMTDAlloc) /* 405 */ CALL(sys_SYNOCaselessStat64) /* 406 */ CALL(sys_SYNOCaselessLStat64) /* 407 */ CALL(sys_ni_syscall) /* 408 */ CALL(sys_ni_syscall) /* 409 */ CALL(sys_SYNOEcryptName) /* 410 */ CALL(sys_SYNODecryptName) /* 411 */ CALL(sys_SYNOACLCheckPerm) /* 412 */ CALL(sys_SYNOACLIsSupport) /* 413 */ CALL(sys_SYNOACLGetPerm) /* 414 */ CALL(sys_SYNOFlushAggregate) /* 415 */ CALL(sys_ni_syscall) /* 416 */ CALL(sys_ni_syscall) /* 417 */ CALL(sys_ni_syscall) /* 418 */ CALL(sys_SYNOStat64) /* 419 */ CALL(sys_SYNOFStat64) /* 420 */ CALL(sys_SYNOLStat64) /* 421 */ CALL(sys_SYNONotifyInit) /* 422 */ CALL(sys_SYNONotifyAddWatch) /* 423 */ CALL(sys_SYNONotifyRemoveWatch) /* 424 */ CALL(sys_SYNONotifyAddWatch32) /* 425 */ CALL(sys_SYNONotifyRemoveWatch32) /* 426 */ CALL(sys_SYNOArchiveOverwrite) /* 427 */ ``` (https://global.synologydownload.com/download/ToolChain/Synology%20NAS%20GPL%20Source/7.1.1-42962/armada370/linux-3.x.txz arch/arm/kernel/calls.S) ``` # 402 is unused 403 common clock_gettime64 sys_clock_gettime 404 common clock_settime64 sys_clock_settime 405 common clock_adjtime64 sys_clock_adjtime 406 common clock_getres_time64 sys_clock_getres 407 common clock_nanosleep_time64 sys_clock_nanosleep 408 common timer_gettime64 sys_timer_gettime 409 common timer_settime64 sys_timer_settime 410 common timerfd_gettime64 sys_timerfd_gettime 411 common timerfd_settime64 sys_timerfd_settime 412 common utimensat_time64 sys_utimensat 413 common pselect6_time64 sys_pselect6 414 common ppoll_time64 sys_ppoll 416 common io_pgetevents_time64 sys_io_pgetevents 417 common recvmmsg_time64 sys_recvmmsg 418 common mq_timedsend_time64 sys_mq_timedsend 419 common mq_timedreceive_time64 sys_mq_timedreceive 420 common semtimedop_time64 sys_semtimedop 421 common rt_sigtimedwait_time64 sys_rt_sigtimedwait 422 common futex_time64 sys_futex 423 common sched_rr_get_interval_time64 sys_sched_rr_get_interval 424 common pidfd_send_signal sys_pidfd_send_signal 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register ``` (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/tools/syscall.tbl?h=v7.0-rc2)

https://go-review.googlesource.com/c/go/+/751340/6#message-2ea0d421236bb61be16d521667f83837d7563c5e

D0lomoidx · March 7, 2026, 1:01pm

Glad I checked here. I thought it was just me. The only clue I had from the log file was “futexwakeup addr=0x1850d30 returned -22 SIGSEGV: segmentation violation”.

dccrens · March 17, 2026, 12:28pm

I ran into this same issue. Watching to see when this gets fixed.

nik684 · March 17, 2026, 12:43pm

I found a solution in another topic but I can’t call it simple. When you install syncthing it has “autoupdate” option turned on already, and it immediately updates to the latest (broken) version and that’s it, you can’t run it anymore.

So right after installation (dont run syncthing yet) you have to change config.xml file and disable that autoupdate option. I had to connect to nas via SSH, download that file and upload a changed one.

If somebody knows an easier way to disable autoupdate (maybe via some synology scheduler command?) then please post this info here.

D0lomoidx · March 18, 2026, 9:19pm

I have confirmed this approach works. Unchecked the box for run after install. I have SSH enabled on my NAS so I used a terminal and vi to edit /var/packages/Syncthing/target/var/config.xml. Changed AutoUpgradeInterval from 12 to 0.

nik684 · March 27, 2026, 7:24am

Hi. Could you please clarify one thing? How users will understand when the issue is fixed and it’s safe to update? Next syncthing update? Post in this topic?

SquiIIiam · March 30, 2026, 3:39pm

Update seems to be available here: SynoCommunity

I haven’t dug into the logs yet but mine still seems to not run with this update.

Nummer378 · March 30, 2026, 6:15pm

The go runtime has been patched with a fix for the Synology kernel issue 5 days ago (runtime: use uname version check for 64-bit time on 32-bit arch codep… · golang/go@04dc12c · GitHub).

However, the fix hasn’t been included in a release of the go runtime yet. A backport to go1.26 is being discussed for the next or the release after that (runtime: regression Synology's Linux fork of linux causes syscall conflict on older kernel versions [1.26 backport] · Issue #77931 · golang/go · GitHub). Once the go runtime has a fix shipped syncthing needs to be rebuilt with that runtime & a syncthing release needs to be made. So overall, this is probably going to require a few more weeks.

In the meantime, it is technically possible to built syncthing with an older go version, or downgrade to an older version. The current SynoCommunity package ships with a version that works (v2.0.14-34), but it seems that this release has auto-upgrades enabled and therefore automatically upgrades to v2.0.15 on startup, which uses the latest version of the go runtime and hence fails. You probably need to disable auto-upgrades before starting syncthing, as mentioned in this post.