I have a system that has a very slow RAID that is also generally not very fast, and sometimes the filesystem would take quite some time to respond. Syncthing is a little bit too eager to declare the filesystem read-only (when it fails to chmod a file in what Syncthing thinks is a reasonable amount of time) and show the folder as out of sync. Even worse, Syncthing never retries these cases, not even upon rescans, so restarting the whole Syncthing seems to be the only way to resume normal operation.
A bug? An unfortunate combination of conditions? Some misconfiguration?
We don’t do any form of read only fs detection, and all failing sync operations should be retried indefinitely (though possibly with increasing delays in between). Explain what you’re actually seeing?
Folder goes “Out of sync”, clicking on “Failed items” has items that list “read-only filesystem” as the reason of failure. Hovering over “read-only filesystem” produces a tooltip that I can’t at the moment quote exactly, but something along the lines of “read only filesystem, chmod /some/file failed”.
So you’re saying that the OS said the FS was RO at some point, and then resumed normal operation? Not entirely impossible, I need to dig into this more.
But in any case, Syncthing never retries these until I restart it. That normal?
Judging by the system’s logs, /dev/md0 has been read-only for several minutes during the boot process (something to do with the fact that the system is quite underpowered for that software RAID to work fast), but has been RW for the last 11 hours at least.
Restarting Syncthing from the web interface made it resume normal operations on this folder.