The setup:
I have two headless Linux servers in different offices, they each have a directory mounted to a CIFS share.
The folder to sync are these mounted CIFS.
The syncthing client I am using is v0.12.15, Linux (64 bit)
Latency between the offices is ~20ms
Files are syncing between the offices.
Content: 15720 items, ~27.9 GiB (seen on both servers)
Rescan Interval: 1800s (30minutes)
The Goal:
Sync the user accessible directory between sites.
Users are currently not using the files in the two sites - I am still in the testing phase of this solution.
The problem:
When a directory is deleted in any of the sites it is removed as are the files and directories within - Good.
Within a minute the directory and sub directories are back minus the files. The files are also removed from the other site - directory structure remains.
I run syncthing from the console, on the server where the files originated are continuous errors from the syncthing command. These are access denied to directories (not files), but any new content on the server is replicated.
Also on the original sites web console I see ‘Out of Sync Items’ count is the number of directories - 2.
Summary:
File and directory replication works.
File removal and modification is replicated.
Removal of directories does not replicate. Remove directories are replicated back instead of removed on the other site.
I had a similar problem where syncthing stated “can not remove directories - not empty” this was caused by temporary files (like thumbs.db / desktop.ini) which I had in the .stignore list. But this does not seem to be the same with your problem because you write that in the first place the folders are removed for a short time correct?
Deleting the files works on the first device but the folders are resync’d back from the second device.
Edit:
Sounds like Synching is deleting what it can and running into some ignored files so it can’t delete the folders. The mtime of the folders change thanks to the deletes and this propogates back through the cluster recreating the directories.
kluppy,
I have not modified any ignore list.
I have looked at the docs and see that ignores are saved in .stignore in the root of the repository.
File .stignore does not exist on either repository.
In that case it it seems like a permissions issue, have you tested manually creating a directory with a file, letting it sync and then removing it?
Also, are there any machines that could be accessing the directories? The number of times I have been unable to delete remote folders because of windows locking a file…
If you provide the specific output from the failing device it might help.
Yes I have accessed the repository via cli on the Linux server and rm -d the_directory, and it does delete, then comes back.
The unix rights look ok for files and dirs: drwxr-xr-x 2 root root 4.0K Aug 10 11:55 Budget
It seems it can’t set permissions, probably because the server denies that for whatever reason. Try checking the “ignore permissions” checkbox for this folder.
Hi calmh,
I managed to check and save “ignore permissions” on one site (site 2).
But the original site (site 1) I cannot select save, the icon changes to the red circle with bar across it.
The setting look the same in both sites nothing out of the ordinary. (that I can see)
Iceberg
I confirmed introducer was not set on either server
Update
Version 0.12.16 is out. I have upgraded my servers.
I can now set ‘ignore permissions’
There are no more errors from the syncthing command
I will continue testing. Looking good.
There is another problem now - not sure if it warrants a new thread.
On site1 I deleted a directory yesterday.
The server was restarted on both sites due to Rescan Interval change from 30 to 10 minutes.
Today I go to create a directory of the same name in the synced directory with a Windows machine (not running syncthing) and get an error that the folder is already open by a different program.
When I create the same directory with the root user on the Linux server (running syncthing) it is created.
Deletion/Creation of this directory with a Windows machine on site2 has no issue.
