Out of space error doesn't go away when there is free space again

Hello. I have noticed an issue: when some of your files fails to sync due to lack of free space, the error doesn’t go away, even after you’ve cleared some space on the drive. I think this looks like a bug, but the some of the members kicked me to the forum and closed my issue.

Can anyone confirm this is a real problem or am i wrong?

Syncthing checks for space in two places, the folder it syncs and the location where it stores its database.

Make sure you got enough space in both places.

Provide screenshots if it still persists.

Also, the forum is the right place to resolve this, as, atleast for now, I think my answer above will be the solution to your problem, hence not actually a bug, hence nothing needs fixing, hence no need for an issue.

If we both, here, arrive at a conclusion that its a bug, we’ll reopen the issue.

All right, i’ll do some screenshots after i finish some busyness, i need to fill my drive up again for that.

Here’s what I see when a folder gets out of disk space. First the files to be synced fail, citing out of space:

Then when I free up some space they get retried and succeed:

However some things:

  • Scanning doesn’t recheck the free space, only the automatic retry to sync the files
  • That retry happens initially once a minute but we throttle it back when it fails repeatedly, up to once an hour I think. So it might take a while if it’s been failed for a long time.

Probably pausing the folder and resuming it should kick it off if you don’t want to wait for a retry.

Historically we used to stop the folder entirely but that’s not what happens at the moment.

1 Like

You sure? Afaik that’s part of the health check together with the path and marker check, and runs before every scan and pull.

90-ish percent, as I thought the same as you but checked the code. No checks during scanning and no stopping the folder for lack of free space that I could see. The only free space check in the folder health check is for the database volume.

Which makes sense, really. Database problem is a stop condition, lack of space in the folder might still mean we can do some changes.

Ah yeah my bad, topic comprehension error: Of course only DB is a health error, the rest is just a pull error indeed - I completely glossed over the distinction here. So I guess the problem here is that there’s no trigger for pull, when space becomes available again (unless something in the folder was deleted, then that’s picked up by the scanner which kicks of a pull).