1 hour ago, binhex said:

Hi, sorry for the delay, i have been sitting on a very large boat for 2 weeks :-). OK ive taken a look at the issue and its simply that the syncthing dev's have made a breakiing change to the cli options, so you now need to specify double hyphens for the cli options, changed my start script and its built and gone through my smoke test and passed, so the new release is now there.

Thanks for looking into it!

I updated from the unraid update utility. After some time (I think it might have been upgrading the internal DB?), it came up and started working again. It connected up to my other Syncthing agent in version 1.30. Now I just have to figure out how to compile version 2.0.2 myself for my other NAS (a Drobo 5N2).

hey there,

i have a huge problem atm. since some days i get this message here for serveral synctargets

2025-08-22 02:39:53: Failed initial scan (error="insufficient space on disk for database (/config/syncthing/data/index-v2): current 0.94 % < required 1 %" folder.label=/media/SHARE folder.id=zuff4-styif folder.type=sendreceive log.pkg=model)

there are some gigs free, on the syncsource and the target.

i did check everything i could, but i dont have a clue whats wrong...

thanks in advance for help :)

update:

found a setting that did help for now... but i still dont have a clue why its under 1%.

Edited August 22, 2025Aug 22 by masterdot

Since it's complaining about the database it's likely a space problem on your appdata volume.

Having my first issue with Syncthing(v2.0.6) on UNRAID 7.1.4. It is useing a lot of cpu resources while seemingly doing nothing. Syncthing is not scanning, transferring data and I dont use "watch for changes". In the past it would us 0% cpu and just site at idle. Now I can pause all folders and remote devices(another UNRAID server with the same specs) and I still get this unless I stop the docker. I have reverted back to older versions of syncthing and nothing has worked. I need some help, Thanks.

8 minutes ago, Xandarr said:

Having my first issue with Syncthing(v2.0.6) on UNRAID 7.1.4. It is useing a lot of cpu resources while seemingly doing nothing. Syncthing is not scanning, transferring data and I dont use "watch for changes". In the past it would us 0% cpu and just site at idle. Now I can pause all folders and remote devices(another UNRAID server with the same specs) and I still get this unless I stop the docker. I have reverted back to older versions of syncthing and nothing has worked. I need some help, Thanks.

Same here, Since the update and database conversion, my idle cpu usage increased about 5% give or take and one of my syncing folders was not always scanning to 100% completion, and sometimes needed the syncthing docker to restart to finish that folders scanning. I thought it was unrelated to my idle high cpu usage.

However I removed that folder and readded it to syncthing , let it scan back in and once complete the cpu usage was back to my nominal usage.

This suggests to me a corrupt / damaged database when it converted one or two updates ago, and was somehow linked to my cpu usage.

So I would suggest removing and readding syncing folders and see if that works for you too, I was lucky as i had a obvious faulty folder share to try first, my other 5 shared folders appeared to be fine. hope that helps

Edited September 5, 2025Sep 5 by scottm8124

19 hours ago, scottm8124 said:

Same here, Since the update and database conversion, my idle cpu usage increased about 5% give or take and one of my syncing folders was not always scanning to 100% completion, and sometimes needed the syncthing docker to restart to finish that folders scanning. I thought it was unrelated to my idle high cpu usage.

However I removed that folder and readded it to syncthing , let it scan back in and once complete the cpu usage was back to my nominal usage.

This suggests to me a corrupt / damaged database when it converted one or two updates ago, and was somehow linked to my cpu usage.

So I would suggest removing and readding syncing folders and see if that works for you too, I was lucky as i had a obvious faulty folder share to try first, my other 5 shared folders appeared to be fine. hope that helps

Thank you, that worked! I actually had a folder that I was not syncing at the moment and it was paused and it did not have a destination folder on the other end. This was my problem, deleted the folder and all is good. Funny thing is I have had the folder there for a good while through many updates and it was never an issue. Anyway thanks again

Anyone get an error in the webui when clicking on the button to update to 2.0.9? Whenever I try I get the erro:

My Puid is 1001, PGID is 100 and UMASK is 002.

Edited September 13, 2025Sep 13 by Android_18

22 minutes ago, Android_18 said:

Anyone get an error in the webui when clicking on the button to update to 2.0.9? Whenever I try I get the erro:

My Puid is 1001, PGID is 100 and UMASK is 002.

You can't update Docker apps internally like that. You'll have to be patient, and wait for Binhex to push out an updated container release.

Dan / Gib.

having an odd issue. Moving a folder /folder from unraid1(just a disk) to unraid 2 (share) and it keeps filling up 1 drive all the time, not spreading it out across the entire array.

Im having huge problems setting this up to connect two unraid servers via LAN rather than using Relay. I just can't work out why it doesn't connect. I'm getting the following errors:

2026-03-20 08:45:48 WRN Failed to listen (QUIC) (error="listen udp 192.168.1.239:22000: bind: cannot assign requested address" log.pkg=connections)

2026-03-20 08:45:48 WRN Service failed (error="listen udp 192.168.1.239:22000: bind: cannot assign requested address" supervisor=listenerSupervisor@quic://192.168.1.239:22000 service=quic://192.168.1.239:22000 log.pkg=connections)

I'm a noob with Syncthing but had it working via Relay connection over internet but after many hours trying to figure out what I thought would be a simple issue I'm lost. Is ther another setting required in the Docker Container. I have mine set to defaults.