Long story made short I had set up a local script to use that would simply pause and resume syncing at specified times to save on precious bandwidth. What I had thought would do the trick and made things super simple was using the REST API and simply calling the appropriate POST /rest/system/pause and POST /rest/system/resume calls and be done with it. At the base level these appear to work fine as I do see the Syncthing logs registering the device as pausing and resuming when the script fires off.
However I noticed while the device is paused, I am still seeing data transfers and bandwidth being used. In one case there was a file consistently being written to while SyncThing was in a paused state and it would periodically register and transfer the new data.
Am I missing something or do these two API calls not do what I really want? Ultimately I’d just like a simple API call that I can temporarily halt ALL activity, and more importantly data transfers and the resulting bandwidth usage.
Paused devices are disconnected. That doesn’t stop some other traffic though, like relay connections, discovery chatter, and incoming connection attempts from the paused device.
If you stop Syncthing you’ll stop the chatter though.
Unfortunate. I was hoping to have to take that drastic of a step. I’m assuming there’s no other way to stop this other than straight up shutting down SyncThing?
One of the roadblocks I have in doing so is right now the script I’m using I can only run under admin credentials in Windows due to the application I have it running under and I’m not sure how SyncThing will behave if it is launched with admin permissions.
I’ve actually been messing with this option off and on as the next possible solution but for the life of me I can’t seem to get the firewall rules to actually block in/out connections. It’s probably something I’m doing wrong and I just need to sit down and hammer at it some more. Here’s essentially the summary of what I’m working with.
Using SyncTrayzor but have made sure to focus the firewall rules on syncthing.exe and the one under AppData as it seems SyncTrayzor likes to run from by default. And I’ve confirmed this is the proper path per the process info in Task Manager.
Set up both inbound and outbound rules in the Windows Firewall pointed to the syncthing.exe process noted above. Set for any IP, any protocol/port, any profile (Domain, Private, or Public) and set to Block all connections. Firewall is also enabled.
I’ll definitely mess with this some more and try to figure out what I’m doing wrong and report back.
@cr08 do you really need 0 traffic? When you pause devices can you see if remaining traffic is inbound/outbound/both ?
I’m interested in this issue as I have a remote script that doesn’t work anymore, supposed to prevent the running device to shutdown when disconnection to my local device is detected (I locally pause the remote peer to prevent shutdown-on-uptodate for maintenance purpose).
I’ll try and take a look and confirm those details later tonight on the inbound/outbound stuff. It does have to be zero traffic. There’s no port forwarding set up between our devices so it should all be going through external relays.
Basically what is set up is I have a friend who streams on Twitch and I have him backing up his recordings to my NAS. He’s got a limited amount of upload at 20mbit rated by his ISP plus other household members so having this cut off completely during that time is preferential over trying any sort of throttling. I have it set up on a Lua script in OBS to pause and resume his device via the REST API whenever the application is launched and closed respectively.
The firewall function would work fine via this method if I could find out why the rules I have set up are not doing anything to the traffic to/from SyncThing.
Ok. So I think I found out why the firewall rules are not working and it seems like an odd Windows quirk.
As noted above, with the way SyncTrayzor sets things up by default, the operational syncthing.exe process is located under
%AppData%\SyncTrayzor\syncthing.exe OR C:\Users\User\AppData\Roaming\SyncTrayzor\syncthing.exe
When adding %AppData%\SyncTrayzor\syncthing.exe as the program path in the firewall rules, if I go back to Firewall and Advanced Security panel and look under Monitoring > Firewall and pull up the same rule, it shows the program path as C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\SyncTrayzor\syncthing.exe
This configuration still allows connections in and out.
If I go back and modify the rule to distinctly point to the user folder, ie: C:\Users\cr08\AppData\Roaming\SyncTrayzor\syncthing.exe going back to the Monitoring tab and checking the rule it shows that program path verbatim. In this setup, the connections are appropriately blocked.
This does add one more extra step for me as I have to find his username as it is in Windows and point at it specifically in my script, but it is a lot less of a headache now!
Hopefully this will help others trying to accomplish the same thing. I’ll put this in play and report back how it goes.
First run through live with my friend’s stream tonight and the firewall rules worked a treat with the info above. His machine showed disconnected on my end for the duration and reconnected at the end when he closed OBS. So all is good now!