Unfortunately I have four problems with syncthing.
The setup is as follows:
Several machines (one Windows and several Linux machines) as a client sync to a Linux based syncthing server. The clients are all configured as write only and the server is configured as read only. The clients each sync one or more directories to the server.
The problems are:
One Linux machine shows up as “not synchronized” and some files as “not synchronized elements”, “failed elements” and “local changed elements”. The files shown as before are listed in all the three categories. If I click on “failed elements” the reason stated for all files are “operation not permitted”. But the permission is set to 100644 (namely read for group and everyone, so syncthing should be allowed to read). What is the reason for this and how to overcome? If everyone has read access it should be OK, shouldn’t it?
Clicking on “reset local changes” does not do anything: Mentioned Linux machine as well as the Windows machine show the button “reset local changes” in their folders but clicking on the button doesn’t change the state. The Windows machine doesn’t show the folder as “not synchronized” but as “local additions”, but the effect is the same (means it does nothing). The Windows machine additionally has its folders set to “ignore rights” as the rights of Linux and Windows are of course different. How to make the button work?
The Windows machine shows up in the list of the machines with 17 elements not synced. If I click on that list it says for some seconds “loading data…” just to show an empty list. So I never know what files are not synced. The machine always stays at 99% synced and never completes. How to populate that list and how to make it complete?
The same directory seen from the client and from the server state differently, making no sense! On the client: Folder: “Current”, external device, not synchronized elements: “3506 elements, 946 MiB”. On the server: Folder: “local additions”, external device, not synchronized elements: “17 elements, 198 KiB”. So what is the case? Both, client and server should state the same number of files on its memory consumption, shouldn’t it? Why does the folder state differ when seen from the client and from the server?
I only skimmed your text and there’s already enough elements and steps to get my head spinning. Could you please post some screenshots of key situations to make them easier to grasp.
The third picture shows a screenshot from MC on the sender, showing that read permission is set for everyone, nevertheless this is not sufficient for syncthing to read the files. It is a user folder, so owner and group are set to that user:
Concerning the second problem, the forth screenshots shows the situation on the sender: The folder is tagged as “local additions” (Lokale Hinzufügungen) but if I click on “Reset local changes” (Lokale Änderungen zurücksetzen) nothing happens, it still says “local additions” and the number of locally changed files does not change.
Concerning the third problem, the screenshot shows an empty list but 17 items should be shown:
The screenshot also shows the situation on the receiver. Consider the state of the folders (“local additions”) and the number and size of elements (17 elements, summing up to 198 KiB). Compare that to the same situation on the sender in the screenshot below. The folder state now is “Current” and 3528 elements summing up to 1.89 GiB. How come the display is different on sender and receiver?
Please also explain, which type of devices you use. It seems you have a Linux and a Android system in use. Are all peers are connected to all the devices?
First problem: It fails to change permissions, meaning the user Syncthing is running as doesn’t have sufficient permission to do so. Probably it’s not the owner of the file. You either need to sort that out at in your system, or ignore permissions in Syncthing.
Second problem: Please enable model and db debug logging (Actions > Logs) and click the revert local changes button again. Then post the logs here.
Third problem: A bug that can cause that is fixed in v1.11.0, so lets see if it goes away for you after the upgrade. It’s only a cosmetic problem, sync still works.
You are right, it’s a mixture of Windows, Linux and Android devices.
The setup is as follows:
The Windows, Linux and Android devices have no knowledge about each other. They only sync one or more folders of their local disk via syncthing to system running under Linux. All systems (the senders) are configured as “send only”, only the one Linux system mentioned last is configured as “read only” (the receiver). A nightly hardlink backup is drawn via dirvish/rsync on the receiver machine.
So except that meanwhile a lot of machines are involved the setup is very simple, all machines that have “something to backup” do a one-way sync of their important folders to one machine that offers a syncthing service. The folders don’t overlap (means only the originating machine and the server know of it, no other machine). This results (or at least should result) in a 1:1 copy of all folders on the server. As said, each night a hardlink backup is pulled of the complete syncthing folder. So I get some time machine like behaviour. The nice things are that it’s fully automated and that clients can connect locally or over the internet, so road warrior’s machines are also backed up without a gap.
First problem: For my understanding, why at all does it have to change permission? No, of course it’s not the owner of the files, it should potentially synchronize any file, no matter whom it belongs to. If it had to be the owner of all files it should synchronize, it would be useless, wouldn’t it? And what would be the sense behind disabling rights? OK, if I sync e. g. files on a NTFS-partition to an Ext4-partition it makes no sense to keep the rights. But from Ext4 to Ext4 this is different, here it should be possible to keep the rights, shouldn’t it?
Second problem: Very(!!) strange! After I set the debugging options as you said and clicked again on “reset local changes” it suddenly worked. I need not understand that, do I? I nevertheless attached the log file. Or at least the section that is of interest, originally it was more than 900kB large and span two days, it makes no sense to attach that!
LOG (11.0 KB)
However sync still stalls at 99% (as said, I can’t see the 17 files that are involved due to the problem three). Maybe resolving this will shed some light on the issue.
Third problem: OK, waiting for the next update.
Forth problem: Under analysis after the change introduced by analysis of problem two.
Syncthing doesn’t sync onwership. It does however sync permissions (which is enabled by default), and if they are different, which they do seem to be in this case, it needs to own the files to change the permissions.
Seems I still didn’t quite understand! In my case a one-way sync happens. Before the very first sync takes place naturally the file only exists in one of two places (the sender). So there’s no way for anything to be different, as it only exists once. After the first sync I expect each file as well as its permission (if the later isn’t disabled) to be equal on sender and receiver. But it came up with “failed sync” already at that time. How come?
But at least I could resolve this(!) issue - by changing the owner of the files on the receiver. A chown -R syncthing:syncthing /path/to/folder did the trick, the Linux machine then came up with Current in SyncTrayzor.
The statement “After I set the debugging options as you said and clicked again on reset local changes it suddenly worked.” unfortunately was too early! After I took a look today it again said “local additions” like it did before!
After I took a look today it again said “local additions” like it did before!
And that’s every time I do so. The state says “local additions”, I click on reset and it now states “current”. However this is not permanent, the next day (or the next time I boot the PC, didn’t find out yet when this transition happens) it says “local additions” without me adding or changing anything. Very confusing. I also remember a time long ago when it didn’t report “local additions”, it always stayed on “current”. No need to click on reset (or, more precise, the button didn’t appear at all). Don’t know what has changed then.
@imsodin, did you see anything that explains this in the logfile I attached? Did the database get corrupt somehow and I should delete the db-files as a last measure? syncthing has been in continuous operation on that system for quite some time, since January 2016. I think this was with V0.14 or even earlier of syncthing and it naturally has gone through several changes of the db format.
I haven’t looked at the log because you said it’s working. That said it isn’t a Syncthing log at all, it’s a log of the leveldb. And to the general question: I don’t see any reason at this point to assume any of the behaviour you describe is due to db corruption.
Anyway if “local additions” reappears, this means the files were changed locally. Check what is different on the two devices (diff and ls -l will do that). If they really aren’t different at all, we’ll take it from there.
