Changes to config not saved

I hadn’t opened the UI on my ubuntu 18.04 system in a while. Synchthing was automatically updated to v1.9.0. So, I realised, that the system wanted to sync one particular folder to my laptop, but I had set my laptop to ignore that folder, for it had grown big and space on the laptop was needed for other stuff. So, I thought I disabled sharing with the Laptop, so that the status wouldn’t always show that the system was trying to sync to the laptop with no progress.

So, I unchecked the laptop and clicked save. But, after a few seconds the system again tries to sync with the laptop, and if I watch the folder settings, the laptop is checked again.

So, I unchecked all systems, and in the UI the folder got “unshared” status, but only for a couple of second, then it reverted back to the old settings, as if the changes were not saved.

What can I do to change that behaviour…?

So it should work and I guess it didn’t, but unless you have a way to reproduce it, it might be hard to track down. Effectively, the folder is doing something it doesn’t want to cancel and we should figure out what that is, from the ui and logs.

As far as I see, all folder settings aren’t changed. Or, revert back to original state moments after a change. So, I guess, the new settings aren’t stored and the webUI then loads the original at next refresh…

Check chrome developer tools network tab as to what happens to the request that supposed to update the config.

Using Firefox, but there is console to.

So, there is a ‘refreshConfig’ triggered. And I can unfold the structure behind it. For the test I disabled all sharing of the folder, and in the structure, under devices there is only one entry, the system ID I am working on. So, that seems fine, right?

After that, lots of other things are triggerd, like refreshes of all folders and recalulations on when any given device for any given folder will be complete.

But I can’t find any obvious error message why the config isn’t saved.

I am interested in the response status code for the post to /rest/config endpoing.

POST
scheme https
host example.com:8384
filename /rest/system/config
Adresse some_ipv4:8384

Status

200

OK

VersionHTTP/1.1

Übertragen 20,55 KB (0 B Größe)

Referrer Policyno-referrer-when-downgrade

I’m not sure if the line after the HTTP-Version is any clue, for it states (in German) “Transfered 20,55 KB (0 B size)”. And I’m not quite sure, what the 0 B size means, is it the payload of the response, when the payload if the request was 20,55KB ?

That looks fine. Are there any errors in syncthing logs? Perhaps it can’t save the config? Does the mtime change as the config is saved?

No. And strangely enough, the problem suddenly vanished. Maybe there was something wrong with the user permissions to the config file.

Where is the config stored anyway?

https://docs.syncthing.net/users/config.html

FYI, the exact same issue is happening for me intermittently. The scenario is as follows:

  1. Web UI stops applying changes to shared folders. Any change to a shared folder (including adding or deleting one) seems to be applied in the UI, then reverts back after tens of seconds.
  2. I usually try few times and give up.
  3. After a while (5-10 minutes), a bunch of errors appear in the Web UI. One for each config change attempt:

“$DATE $TIME Decoding posted config: read tcp $SYNCTHING_HOST:8088->$MY_LAPTOP:$SOME_RANDOM_PORT: i/o timeout”

  1. Once this happens, this is an indication that something had unblocked. Changes to shared folders are being applied again.

So far I have observed it three times. Syncthing version 1.9.0 and 1.10.0-rc3 (I have two devices). Both syncthing instances running on slow devices - D-Link DNS320L using Alt-F firmware.

I am using Chrome on a Mac. Once syncthing is in the blocked state, opening the WebUI in parallel in Firefox does not help: UI in Firefox is blocked in exactly the same way.

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