Stuck syncing (puller - invalid argument)

This folder used to work. It is on a external HDD. Recently it stopped syncing, with the log showing:

2022-09-19 19:14:03 Puller (folder "ABC" (abcde-12345), item "snapshots/test/00006.MTS-00:00:41.437.jpg"): syncing: opening temp file: open /media/user/1234-ABCDEF/ABC/snapshots/test/.syncthing.00006.MTS-00:00:41.437.jpg.tmp: invalid argument
2022-09-19 19:14:03 "ABC" (abcde-12345): Failed to sync 201 items
2022-09-19 19:14:03 Folder "ABC" (abcde-12345) isn't making sync progress - retrying in 2m1s.

Any suggestions? I did a search, and there are many topics regarding not syncing, but I did not find one with a log like this.

Ok, so the drive is FAT32, which does not allow " : " in filenames. I replaced them all with underscores. I also ticked the box to ignore permissions. I also took the drive to a Windows machine to check for errors.

Yet, still the " : " shows up in the Syncthing log. I did restart Syncthing after every change. Is there some cache or similar that needs clearing?

Can you post screenshots of the Syncthing Web GUI from both sides? Please make sure the errors are visible on the screen, and also that folder info is unfolded, so that both local and global states are displayed.

Thank you for your reply.

I think, I found the problem. There is a remote Mac also on that folder, adding that colon in filenames.

Is it possible to make those error messages more verbose? Like: Who tries to do what? Who complains about that? etc. That would be helpful information, I think.

Yeah, the error messages aren’t exactly ideal, although to to be fair, most of them come from the operating system, not Syncthing.

Syncthing does have some additional information displayed, e.g. when trying to sync files with illegal characters to a Windows device, but that’s only possible, because those restrictions are on the operating system level, regardless of the filesystem in use.

Here, the problem is with the specific FAT filesystem, so to make this work, Syncthing would need to detect the filesystem first, and only then display the appropriate error message. One problem is that reliable filesystem detection can be flaky or plainly impossible (e.g. on Android).

1 Like

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