What you’re showing looks like basic VPN configuration. It has nothing to do with network mounts. So to be clear: You’ve established a VPN connection between the devices. Do they mutually show as Online?
I’m literally not understanding the problem enough yet to really help. Did you check the list of locally added items? Does anything in there make sense to you? Have you checked what the listed items actually look like on disk (or maybe not, because they are actually deleted)?
With that procedure, you need to carefully distinguish between deleting the folder (and its containing files, from the disk) versus removing it from Syncthing’s configuration (Edit > Remove).
Remove it from the configuration on the receive-only side.
Correct.
Should happen pretty much immediately after the restart and re-establishing the connection to the other device. Make sure to point it at the same path, where the files are still present.
Hoping should not be necessary. The sender device will inform the receiver about its known state of the folder. If the global state doesn’t match at this point, you’ve probably hit a bug.
Likely not, I think it just marks the file as not caring about the actual file permissions. You do have “Ingore Permissions” enabled on at least one side, right?
The list of Locally changed items just shows a list of folders which exist in the Send only and Receive only. It is flat out wrong!
That said, the system should alert me about all the actually missing folders and files, but it simply says “Up to date” on the Send only system and “Local additions” on the Receive only system.
I am trying to be as precise as possible, but I sometimes just do not know the proper terminology on trunas/syncthing.
I went ahead with removing the folder and it is still scanning… Here is a quick snaphot showing the progress.
The global state count looks correct, but shouldn’t the local state be 0 when I am still on the initial scan or is it already copying stuff while scanning?
Just a quick update. It is now syncing folders and files. The global count has remained the same which is good I think. The local count is a different story. At times I am suspicious that it hasn’t removed any local folders and files.
Anyhow, it still has like 582 GB to go. I will post an update tomorrow, but I think it will take a few days to complete.
Nevertheless, I care more about the end result than the time it takes to get there. In a home environment, I cannot expect network speed wonders!
“Mounting” usually refers to making a remote filesystem available as part of your local system’s file name space. E.g. mapping a CIFS share as a drive letter in Windows.
The “global state” takes into consideration all currently announced items in a folder as collected from all involved devices. For a receive-only folder, that’s basically the index data which the remote devices sent. For other types, it includes the local state as well. It is normal that these numbers rise gradually after adding a folder, as index data is coming in from remote.
The “local state” is updated by scanning what the local folder currently contains. This also takes a while, thus numbers can rise slowly at the beginning until the first scan is finished.
“Local additions” in a receive-only folder can actually be deletions as well. If you see a folder listed there that is not on the receiver’s disk, it means that it was once there but then deleted. Basically it says: “This device has received the state from the other devices, and on top of that / additionally, a change was made. The change is deletion of a folder.” That’s why it’s called “local additions” even for deleted items.
If the global state doesn’t match between devices (after it has settled), that’s a bug in the index data exchange. We’ve seen such situations sometimes and it’s still not clear where the cause lies. But the remedy is clear - removing the folder (from Syncthing) on one or both sides, adding it again with the same settings. Another way to do that is the --reset-database command line switch, but it affects all of Syncthing’s folders.
Other possible reasons are mismatching ignore patterns (ruled out in your case) and not yet completed index data exchange (needs only patience). If you don’t see the global state rising anymore, and it’s stuck below the numbers which the other device tells you, then you’ve hit the known, but hard to reproduce bug. On the forum you can find several topics about that.
Syncthing will not delete any local items (even in a receive-only folder) during first synchronization. Which this is in your case, after adding the folder again from scratch. When it finishes syncing, any additional local items will show up as local additions.
Sorry I previously misread that. If the items are on both the sender and receiver side, but still show as local additions, then something else about them must be different. Look at the metadata (permissions, modification times) and make sure you’re not trying to sync permissions or other extended attributes.
The status shows as Local additions on the receive only side, but it says Up to date on the send only side.
The locally changed item list only shows folders. However, I have manually confirmed that all folders do already exist on the send only side.
Hopefully, this is more clear now. Basically, I don’t understand why it claims that folders have been locally added even though they do already exist on the send only side.
The option not to sync permissions is set for all folders!
Quick update.
Global state has remained the same and locally changed has disappeared for now. Very good. I will give another update tomorrow!
That is normal. If the sender has all the data comprising the “global state”, it is Up To Date regarding its own assessment. That doesn’t tell anything about whether other devices have the same state. You can judge that under the respective remote device panel on your sender’s GUI.
“Locally changed” means that the local files do not match what Syncthing knows about how they should look. Whether they are present on the sender side has nothing to do with that list.
And an “addition” actually can really mean any difference between recorded metadata and what’s really found on the filesystem. Even a locally missing folder (because it was deleted, not because it is yet to be synced) counts as a “local addition”. Or if the modification time (for files) has been altered after syncing.
Great to hear that it seems to be progressing and you don’t have the big red button anymore. In any case, the global state now matches between both devices, that’s the important bit. The rest is just waiting for it to finish syncing and if the button should really come back, then press it and that will force the receiver to look like the sender’s folder again.
I can now report that the re-synchronization process has completed and all folders are in Up to date status.
While I still don’t understand/know the root cause of my initial issue, I can now say that things are back to normal. Hopefully, it will stay this way.
Once again, a big thank you to @acolomb for taking the time to explain things to me and for providing me with a solution for things to go back to normal. Your efforts are very appreciated!!
