New / modified files from laptop not syncing


I’m a little confused about how to get my setup to work

To start with, I have a Debian VM “Debbox” that I use as “introducer” to other devices (I think of it as the “hub” between all the devices)

I have a w10 laptop on which I do most my work. I cloned the SSD from a desktop, so most of the files were already present when I set it up

I re-installed Syncthing (Synctrayzor 1.1.24) on the laptop and added the device (new name) to my main Syncthing VM “Debbox”

Since then, I have created new files in some of the synced folders, but my files are not being sent to the other members, and I am getting this error on the laptop:

handling file: file modified but not rescanned; will try again later

And also this error:

no connected device has the required version of this file

BTW I have the “Introducer” Debbox set to “auto accept”.

The only folder that isn’t out of sync is the one that doesn’t have any files modified on the laptop.

Does anyone know what I should do?


At a guess, you might have files on the two devices that differ only in case (document vs Document). This results in really odd things, like what you’re seeing. It’s a bug, unfortunately one that’s tricky to solve.

Thanks for replying to my question

The files themselves don’t differ in case, but the platforms do differ in filesystem case sensitivity (ie NTFS vs EXT4

Any suggestions for a workaround?

Well, as a starting point, I realized the package maintainer’s version of Syncthing is v1.0.0 while Synctrazor’s current release 1.1.24 ships with Syncthing 1.4.0

I downloaded 1.4.0 on my Debian machine, stopped the systemd service for it, and am running 1.4.0 from user prompt as a test to see if that clears anything up.

Didn’t fix anything just by getting the versions to be equal. Just restarted Syncthing on Windows and it’s giving me the same errors:

handling file: file modified but not rescanned; will try again later
Failed to sync 73 items
isn't making sync progress - retrying in (...)
no connected device has the required version of this file

I’m bummed, I was really hoping the upgrade on Debian would do it. I’ve gotta find some way to get this resolved, I rely on Syncthing (and these files) a lot.

Well here’s some info that looks helpful: Case-only renames break stuff · Issue #1787 · syncthing/syncthing · GitHub

Specifically, this person tried a test with mv-ing a file to a version with case, and when syncing the file from Linux to Mac, the file actually disappeared - and then deleted the Linux copy, as well! :astonished:

Pretty scary. Thank god I have .stversions set up.

In my case, I created a file ‘testfile1’ in Linux, observed the file being synced to Windows - and also this error message:

<foldername>: Failed to sync 1 items

Renamed the file in Windows to Testfile1 - on Linux both exist:

'Testfile1 (Case Conflict)'

If this happens en masse, it’s going to be a huge PITA to clean up.

Yay! Finally resolved!


Main “hub” (Debian VM):

This comment in the issue thread on Github caught my eye as being worth trying:

and it appears to be working for me.

I’ll try to make this tidy so if anyone else having the same issue comes across the thread they can follow along.

In Linux and Solaris (OmniOS), the index-db files were in:


In Windows, the index files were at:

/c/users/username/Local Settings/Syncthing/index-v0.14.0.db

(path as output by mingw64 “git bash” terminal)

On Android, in the Syncthing app there’s a “reset db” option under “troubleshooting”


  1. Stop all instances of Syncthing on network
  2. Delete all index db files on all devices (rm * inside the index-db folder)
  3. Restart Syncthing on all devices

I started by running Syncthing on the laptop I was having issue with first, too - since it had all the new files that weren’t being synced. I am not sure if this made a difference, but I thought it might be worth mentioning.

Hope I don’t run into these issues again, but at least Syncthing is pretty friendly about rebuilding its indexes after being manually deleted.

Moderators: Could someone please mark the thread resolved?

Thanks :slight_smile:

It’s important to note, I am going to make all my Syncthing folders in Windows case-sensitive. (I had no idea I even could - apparently it’s a feature that was added in 1803)



It can be kind of difficult / time consuming to do this for each folder, so I looked up how to do it recursively using a PowerShell script.

Here’s the process:

First, you have to enable WSL to be able to implement case sensitivity in Windows

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

To recursively enable case sensitivity to all folders inside folder:

(Get-ChildItem -Recurse -Directory).FullName | ForEach-Object {fsutil.exe file setCaseSensitiveInfo $_ enable}; Write-Host $_

To enable case sensitivity of a single folder (from parent folder):

fsutil file setcasesensitiveinfo "FolderName" enable

The first command that enables case sensitivity recursively doesn’t enable it for the folder it’s run from, so it’s necessary to run the first command and then change to the parent directory and run the command for the single folder on the folder you were just in.

Hopefully now I won’t see any of these case sensitivity mismatch errors anymore.

1 Like

This process I used also with v1.4.0 and since this timepoint all devices runs perfectly.

The change in the database structure since the last version 1.3.4 needs a Migration after update to the current version, but is not working in my cases.

1 Like

Just to prevent any misunderstandings by people reading this:

The upgrade to 1.4.0 does not require a database reset.

Resetting the database should never be done lightly - create a thread on the forums discussing your problems and the way forward first. @averyfreeman did their due diligence first and found a solution that worked and that’s great. With lesser care you might just create more problems instead.


Just to further emphasize precisely that…

Migrating the database requires reading and re-writing every file entry, and in some cases this turns up pre-existing corruption. We’ve put a fair amount of thought into repairing and fixing such corruption when encountered, but sometimes there are cases we didn’t anticipate.

There’s tens of thousands of users on 1.4.0 and a handful of known migration failures so far.

I don’t think this issue had anything with the migration to do.

It wasn’t meant to be like that. Of course the reader have to know the story you both know about it in my cases. I did not mean that this is generally necessary. As you know, there were things that I couldn’t fix with the available tools, maybe I have Synologys or because of others reasons.

That is why I also expressly say here that anyone who changes from <v1.4.0 to v1.4.x does not have to do anything if all processes are running.

1 Like

Yes, thankfully I only have ~10GB of synchronized data. I couldn’t imagine doing it with far more than that - I think I read one thread where re-creating the db (rescanning all the files from scratch) would take upwards of 10 hours, so not everyone will think this solution is all that ‘easy’.

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