This was always a requirement when you want to synchronize permissions, because that’s how chmod works. Only the owner can change file permissions. Maybe you can work around this with capabilites, though.
* Bypass permission checks on operations that normally require the filesystem UID of the process to match the UID of the file (e.g., chmod(2), utime(2)), exclud‐
ing those operations covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH;
* set extended file attributes (see chattr(1)) on arbitrary files;
* set Access Control Lists (ACLs) on arbitrary files;
* ignore directory sticky bit on file deletion;
* specify O_NOATIME for arbitrary files in open(2) and fcntl(2).
I’m guessing that in the original setup the files “originated” on the more locked down side, so there was never any reason for Syncthing to attempt to change the permissions there.
In the upgrade, since the index is recreated, Syncthing reconciles any differences detected, and probably does a chmod with the existing permissions even when they haven’t changed - not sure, would need to double check the code. That then triggers the error.
So yes, it should always have had “ignore permissions” set, but I can see that it might have sort of worked before.
OK, I see that I can reduce the impact of flooding by running logrotate more than once per day and using maxsize.
This is clearly more general and st shouldn’t need to do this.
This is fine for current users of syncthing. However, I don’t think it is acceptable for st 1.0.0 to produce so many log messages for what is, essentially one error.
All I can think to do, as a backstop, is to count messages, and if the count in a period of time (1 minute?) exceeds a threshold (6000?) more than n(3?) times in another period (1 day?) to die with a suitably unhelpful message like Stuff is wrong, see the log.
However, I don’t have any suggestions how to fix the underlying problem - that one configuration error can cause a flood of error messages, possibly affecting the stability of the system.
That would require forethought, design of multiple detection mechanisms without affecting performance too much etc. This is far too difficult for me… And it’s peripheral to the main function of st.
Perhaps all that can be done, apart from a backstop, is to compile a prominent list of gotchas in the documentation.