Could you try https://cdn.kastelo.net/tfi/syncthing-linux-arm-v2-0-0-rc-16-dev-8-g1b8a8032-v2-tar.gz (from build: target ARMv6 for linux-arm builds · syncthing/syncthing@1b8a803 · GitHub) and see if it works on your Pi? I made an attempt to select a fairly baseline ARMv6 instruction set.
1 Like
Trying to figure out a good way for macOS users to test this. Should we just replace our syncthing binary inside the 1.29.6 app bundle?
You can try it. Personally I run it from launchd without the GUI, so I’m not sure. 
Works for me on the pi 1, thx
1 Like
Today, on one device after rebooting the OS and starting Syncthing in the process, I’m experiencing the Web GUI being completely stalled:
It has been in this state for ~40 minutes or so, and the device in question appears disconnected on other devices. The hardware is decent, and normally everything works just fine.
I’m uploading a full goroutine dump below. I also wanted to take CPU and heap profiles, but I cannot, as the browser just keeps trying to load the /rest/debug/heapprof URLs (as by https://docs.syncthing.net/users/profiling.html) with no end to it.
- goroutine.txt (378.1 KB)
The log is also basically flooded with these:
[3KHRD] 2025/05/24 18:57:35 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:22000: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 18:59:51 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:1139: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:00:06 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:1139: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:00:20 INFO: Listen (BEP/tcp): TLS handshake: read tcp [fe80::d5c2:2f0d:e1d2:13ce%Wi-Fi 4]:22000->[fe80::2c0a:f886:fe67:b899%Wi-Fi 4]:60859: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:01:06 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:22000: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:02:26 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:22000: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:02:37 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:1139: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:03:51 INFO: Listen (BEP/tcp): TLS handshake: read tcp [fe80::d5c2:2f0d:e1d2:13ce%Wi-Fi 4]:22000->[fe80::2c0a:f886:fe67:b899%Wi-Fi 4]:22000: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:04:57 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:22000: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:06:22 INFO: Listen (BEP/tcp): TLS handshake: read tcp [fe80::d5c2:2f0d:e1d2:13ce%Wi-Fi 4]:22000->[fe80::2c0a:f886:fe67:b899%Wi-Fi 4]:60882: wsarecv: An existing connection was forcibly closed by the remote host.
[3KHRD] 2025/05/24 19:08:53 INFO: Listen (BEP/tcp): TLS handshake: read tcp 192.168.50.253:22000->192.168.50.1:22000: wsarecv: An existing connection was forcibly closed by the remote host.
This is Windows 11 x64, and Syncthing has been built from https://github.com/tomasz1986/syncthing/tree/tomasz86/releases/tomasz86-v2.0.0-rc.16.
I’d be very grateful if you could have a look at the goroutine dump and let me know if there is anything obvious in there 
.
Edit:
I had to bring the device back to life, so I just killed the Syncthing process and restarted it. After doing so, it launched and began to sync as usual, so I’m really not sure what had happened before…
2 Likes
Fiddled around a bit, as I definitely wanted to test this on macOS before 2.0 goes final. But, no matter what, syncthing kept crashing.
Finally figured out the problem—the wrapper was still using the old single-dash longopts.
I updated my build script to fix this, and it mints a properly-codesigned 2.0-rc.16 macOS app bundle.
I also just submitted PR#249 to syncthing-macos @xor-gate
Otherwise, so far so good 
— hopefully this helps the next brave adventurer.
3 Likes
This docker image gives a manifest error. Is there a new one?
ghcr.io/syncthing/syncthing:v2.0.0-beta.16
Yes, works. Thanks for the quick reply. Maybe someone can edit the first message here to fix.
That would be 2.0.0-rc.16, not v2.0.0-beta.16.
Debian worked fine. I need windows and macos builds. I guess is ok to run mixed old/new for a bit?
If you mean mixing v1 and v2 devices in a cluster, that should work fine.
1 Like
Also there are of course Windows and macOS builds linked.
1 Like
Official Syncthing for macOS bundle and status icon has a v2 branch and first bundled pre-release. Lets see how far we can go. I’m not going to test this on my production systems and data just yet. Release Syncthing for macOS v2.0.0-rc.16+1 · syncthing/syncthing-macos · GitHub
1 Like
@xor-gate thank you for the build, just curious why you chose these words: “Initial release which bundles the upcoming incompatible v2” – what is incompatible? I tested v2 syncing with two v1 nodes and it worked fine. Are you talking about the db change from Level to sqlite?
1 Like
I’m not very active about the discussion on v2, but v1 and v2 are major version bumps. Probably in the future the API is incompatible. I wanted to be on the safe side beforehand.
Receive-encrypted folders are showing out-of-sync 95% 0B after files are deleted on one side.
Fuller explanation: two Linux laptop and RPi4 share a folder. The Pi has this folder receive-encrypted the two laptop are send-receive.
Laptop A will fully sync with the Pi. Later, with laptop A disconnect, laptop B comes online to share data from the Pi, which results in out-of-sync 95% 0B on laptop B for a few files that were deleted earlier by laptop A.
This is resolved if the data on the Pi is removed and re-synced as send-receive.
I didn’t take a screenshot of the out-of-sync state on laptop B before resolving the issue with send-receive, sorry.
Edit: To be clear, the two laptop share the folder in send-receive mode and share with the RPi4 as receive-encrypted. This arrangement worked flawlessly with v1.
Edit 2: I suspect the files involved were all 0 byte cache files deleted on laptop A, synced to RPi4 but not updated/cleared from the database on laptop B.
All is well again with rc.17. Thanks to @calmh
I don’t really think anything changed on that front. I couldn’t reproduce the issue.
Sorry, been away for a long weekend. This is not unique to v2. It’s been an occasional issue on 2 x remote computers for several months on v1. When it appears, I simply restart St. I put it down to Synctrazor compatibility