I am having the same exact issue, but from windows machine to windows machine.
Err:“syncing: shortcut file (setting metadata): Access is denied.”}}
Now what I’m finding out is if I sync ownership of the file or folders I get this access denied error. IF I turn that off but only sync the extended attributes it works just fine.
In my use case I have a DFS-Namespace and I want to use Syncthing to keep the two file servers in sync. I can not seem to figure out why syncing ownership is failing and doesn’t seem to be a topic most people here are familiar with. Most posts here suggest to select the option “ignore permissions” and let the destination folder determine inheritance of owner and permissions. Which in the case of your android phone it might be fine.
You both have some sort of permissions issue, I’m not sure there’s anything relevantly same about the causes though. In your case, since you’re getting permission denied when syncing ownership, I would suggest making sure to run with permissions to set ownership, whatever that means on Windows. Local admin, local system, something?
Very odd, that it shows 104 pages of nothing… it should show lines of file paths with error messages on each line indicating what’s wrong with each file.
How long have you tried waiting for the Out of Sync Items list to populate? Sometimes it takes a while, especially if the storage is slow in terms of I/O (e.g. a mechanical hard drive).
For what it’s worth, I just fixed a similar problem, where my Windows local machine was reporting being out of sync with my Linux server, by removing the folder from both ends and recreating it with a new ID.
I had a disk OOS event on my Linux box fairly recently, so I’m suspecting that the index was corrupted through no fault of SyncThing’s. I’m unsure why it wouldn’t have recovered on a rescan, though.
In my case, the local machine was reporting a Global State of 3300 files vs the reality of 1100. The remote machine was reporting the correct 1100 in the UI, but perhaps that’s not what was being reported to the other machine in the metadata? It might explain why there’s those pages of “ghost” files being out of sync, as I had the same experience – there isn’t actually anything that’s out of sync, but the numbers are wrong.
I am encountering the out of sync error, with no resolve option givenin the webUI. Here’s an example of one of the errors (they’re all the same issue, just different files):
NIN/Community Remixes/00801 - 01338 - Emptiness - Echoplex (Only Human Mix).mp3 syncing: finishing: opening temp file: open /data/music/NIN/Community Remixes/.syncthing.00801 - 01338 - Emptiness - Echoplex (Only Human Mix).mp3.tmp: permission denied
When I connect to the system that is out of sync and attempt to list one of these tmp files that’s causing the problem (in order to confirm permissions), the file does not exist.
Background info, this is (so far) over 62k files comprising over 500GB and counting worth of mp3s. The files are on a deduplicated ZFS volume, and there is more than enough space. I’ve deleted all traces of the linux server’s copy of the sync, and everything works…at first. But, by the time I get through the 79k+ worth of files the out of sync error rears it’s ugly head and it’s once again due to files that don’t even exist.
Thoughts?
another log entry, from the post-removal-re-add completion:
syncing: finishing: opening temp file: open /data/music/NIN/Community Remixes/.syncthing.00801 - 01338 - Emptiness - Echoplex (Only Human Mix).mp3.tmp: permission denied
