Errors encountered during chmod operation causes runaway retry loop

[dhowland]

As reported on the forms, here, and in ticket #2727, certain configurations of ACL on FreeBSD/FreeNAS will cause a chmod to fail during file sync. When this happens, errors like these are seen on the console:

Puller (folder "xxxxx-xxxxx", file "Photo/IMAG0594.jpg"): dst create chmod: chmod /mnt/Documents/user/Desktop/Photo/.syncthing.IMAG0594.jpg.tmp: operation not permitted

These errors are repeated over and over for all affected files, during which processor utilization is observed to be 100% of a single core.

The sync state in the webGUI will appear to be stuck at whatever proportion of the dataset is affected. In my case this was 0%. On the NAS, all files were in place, however they were all renamed to .syncthing.*.tmp.

This issue popped up in the past as #1404. At that time, a workaround was added to use "Ignore permissions". That workaround does work to alleviate the ACL issue.

However, syncthing should abort the sync and report an error message to the user when it fails the chmod, similar to how it acts with other permissions issues (populating the "Failed Items" field and reporting the "operation not permitted" on each file). It should not go into a runaway retry loop.

[calmh]

I think the behavior is exactly the same as with other permission issues? It might look runaway because each operation is retried several times, for all affected files, every minute.

[dhowland]

But, for example, if syncthing doesn't have write access to the shared directory, it will populate the "Failed Items" field with the errors for each file. In this case it never gives any indication that there is a problem. It just sits at "Syncing (0% )"

I let it go for 45 minutes, it never stopped grinding. After setting Ignore perms and starting over, it synchronized in about 2 minutes. If it's not technically a runaway loop, the symptom is close enough in my book.

[AudriusButkevicius]

We it prints a message telling you to check the log whi hexplains the failure.
The loop is definately not a runaway loopas it gives up for a minute after 10 attempts for every file.

[dhowland]

We it prints a message telling you to check the log whi hexplains the failure.

I never saw anything like this.