I use sync files from several Windows and Linux boxes and one off-site node onto a large USB drive on a Raspberry Pi. Three folders are sync’d, 2 receive only and 1 send only. But lately, they’re stuck in the “Unknown” status. Running v1.15.1, the most recent distro for the Pi distro package.
Syncthing on the Pi shows only “Unknown” status for the 3 folders, when I log into the syncthing GUI from another networked local computer. The Rescan-all button on the GUI does nothing. Opening a single folder shows a grey-ed out Rescan button. I can pause and unpause all 3 folders, but they go only to Unknown status.
Remote Devices show Up-to-Date, or Syncing, or Disconnected at various times. All other aspects seem to be “working”, but the folders on the Pi are stuck in an Unknown state. With no specific error messages, I’m not sure how to proceed/debug.
Any ideas on the cause and how to fix it?
From my experience, the “Unknown” state usually happens when Syncthing struggles to read the folder state from the storage. I’ve had seen this a lot on devices with very slow storage, e.g. mechanical HDDs or SD cards and similar. My guess would be that the “large USB drive” is likely the culprit in this case.
Does the state still persist if you leave everything alone and come back after a few hours? Also, if the Syncthing’s database is located on the same USB drive as the folders are, then I’d suggest to move it to the internal storage instead (or any other storage device).
I think some more recent releases included improvements in this regard. The GUI’s request for the folder status was basically blocking on some other I/O intensive task, which can take a long time with a low-performance computer and slow storage.
@tomasz86 The “Unknown” state still persists after days. Today, I got some weird I/O errors, and a new error message in the GUI top area: 2021-10-18 19:34:52: Database indirection GC failed: leveldb/table: corruption on table-footer (pos=209394): bad magic number [file=326580.ldb]
Tried deleting one of the folders from the Pi, and it’s automatically returning. Tried deleting the folder, then restarted Syncthing. Folder came back. Hmm… something doesn’t seem right.
Yeah, the errors don’t bode well, I’d say. Are you sure the hardware itself is all right?
The error is not about the folders, but rather the database. Please check where it is located first, and then possibly move it to the internal storage, if possible.
Database is on the root partition. Data is on a USB drive. I deleted the database and rebuilt syncthing. Worked good for 3-4 days, then corrupt database errors again. Data error was on the same folder. Because this folder was “receive only” I shutdown syncthing and am running rsync mirroring until an error occurs. No errors so far for 3 days.
If rsync works fine indefinitely, but syncthing crashes after a few days, then I’ll start thinking it’s a syncthing issue.
In the meantime, I notice that rsync and syncthing slightly disagree about what is synchronized. Has anybody found the magic combination of configuration settings so that when syncthing is “complete”, rsync agrees? And visa versa? Only thing I know so far is that syncthing doesn’t sync folder mod times and does only r/o permission bit. Even ignoring folder mod times (-O option), rsync still does a lot of updates to a “syncthing sync’d” folder. Any way to make syncthing or rsync ignore whatever the permissions are?
No idea about rsync, but I’m going to repeat myself saying that those kind of errors indicate a hardware failure. I’d suggest checking the storage device for them, e.g. by doing a basic SMART check and possibly a full scan for bad sectors. Checking/replacing the cables may also be useful.
The syncthing database is on the root partition, so I didn’t dismount it to run diagnostics. One step at a time. First, I know the data drive is good because I’ve run diagnostics, run rsync on the same files, and did a bad sector scan. Now I’ll see if any other program has problems with the root partition.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.