Server is Out of Sync & cannot Override?

Not sure if this belongs in the Android support room or not, as I am using the Android client to sync to my Windows server - and it’s the Windows server that has the issue.

Android v0.14.16 Linux ARM Server v0.14.17, Windows (64 bit)

Trying to sync my “Camera/Photos” folder to my server. I sync manually once every few weeks; so, there’s massive changes between each sync each time.

NOTE: My Android folder share settings is set to MASTER.

  1. Android client had an “Out of Sync” today, as well as the server - they didn’t match though.

  2. On Android client, i had to go into the Web View and click “Override”. It finished syncing, and shows everything correct.

As you can see, all is well and fine in Android client land.

3) ISSUE: Server continues to show "Out of Sync", showing 4 files not copied to the server yet.

The Server folder settings does NOT have the “Override” option, whereas the android client had it and let me click it. I suspect this is because I have the android client folder settings set to MASTER?

Do I have to remove the MASTER setting on Android to allow me to Override on the server?

I also noticed that it looks like one is partially in progress of being copied. Should I delete that manually and see if it restarts?

If those 4 files were copied to the server, everything (folders, files and size) would be in 100% harmony.

Tried restarting both client and server syncthings multiple times.

Any help is greatly appreciated.

Please read the docs to understand what master means. It’s just trying to sync the 4 missing files.

Thank you. I have; but, it has been “trying to sync the 4 missing files” for 3 days now without success.

Zero bytes transferred for days. Multiple restarts of operating systems, syncthing, etc.

Other files are copied and sync’d. But, not these 4?

Also, I noticed that the first file shown in that screenshot goes back to nothing transferred off and on.

Check the logs

I have a similar issue with Linux to Linux clients. Version is v0.14.17 Although I think I have tracked down the issue to Syncthing not being able to handle a directory name with open/close brackets () in it. syslog:

Dec 29 13:37:22 LON-Monitor syncthing[15473]: [UJ5JT] INFO: Puller (folder “zcmgw-xdny7”, dir “001 - Account Pricing/THAILAND/Bankok Insurance Public Company (Drop Box)”): delete: remove /media/lon-share/actuary/International Property/001 - Account Pricing/THAILAND/Bankok Insurance Public Company (Drop Box): directory not empty

File names with bracket can sync.

As the log says, it can’t delete this directory because it isn’t empty. It probably has an ignored file inside it? Take a look, see what’s going on.

In my case I have shares in different offices synced with Syncthing. This is a directory that was created by a user on a share (local), it was full of files. It synced to another location (remote). The user no long wanted these files so deleted the directory. This action did not sync. It was removed from the users share (local).

I ran tests myself creating directories and putting files in, allowing it to sync then deleted it. All good.

As a test i manually deleted the directory from the remote share. It was removed. So now there is no issue except the out of sync error still persists for these 2 locations: Local site:

Remote site:

1 Like

This specific issue is a known issue we are working to fix.

1 Like

A workaround that has worked for me: I create empty directories on the ‘source’ machine with the names of the deleted directories. The resolves the “parent is not a directory” situation and causes the “parent is not a directory” Failed Items to disappear from the ‘destination’ machine Once resolved, i then delete the empty directories from the ‘source’ machine.

This is sometimes quicker than removing the folder on all devices and then re-adding.

(I should add that sometimes finding the names of the directories to add can be a bit of a challenge - I had to go to my backups to see what the structure on the source machine was the previous day)

The latest release should address this.

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