I am in looking to setup a dedicated sync device at my home and at a remote family members house to allow us to easily share data between locations and provide remote offsite backups.
I will have a small, lower power consuming PC device that is always on at both locations that will be dedicated to only running syncthing with a USB drive attached to it for receiving data. These devices will be running Debian Linux and my goal is to mount various shares local to each house on these central devices and share from there(eg: Setup a Samba share on my laptop and mount that share on my local syncthing device). I would then point syncthing at the mounted directory and tell it to sync to the other remote device. However, if I power my laptop off, the mount on my local syncthing server would break and it would appear to the application as an empty folder, which I think would then cause it to delete everything on the remote backup server at the other house.
Can syncthing handle this sort of backup situation?
Is it possible to configure syncthing to check to see if a mounted network drive is actually mounted before doing a sync?
It does that already, but I know there are a few rare edge cases/bugs where some number of files can get deleted by accident. I was asking @calmh how to handle it, but never got a response.
Good to know. In my case every share would have the source set as “Folder Master” and would only be syncing 1 way. I don’t suppose that setup eliminates any of those edge cases you are mentioning by any chance does it?
To me this seems like the confusion would occur if you were doing a 2 way sync of changes, the drive went offline, someone changed something in either location, and then the drive came back online.
Actually, now that I checked the bug it seems that it’s the opposite, deleted files can reappear when you disconnect the drive randomly, so you should be fine. If not, raise a issue.
Yes, i should be good here. For the folders that will be shared with my family at the remote location, a Samba share will be setup that points to the destination dir syncthing writes to so they can access the files, but their Samba share will be in read-only mode so there’s no way anyone other than me could edit the files on the receiving end of this setup.
I assume you are using linux. In that case the following command (executed before you mount something to it) should protect your mountpoint in basically all edge cases:
chattr +i /mountpoint
It makes the mountpoint immutable and not even root can write to it. That should also prevent the mentioned bug from occurring.
For anyone looking for info on using Syncthing to sync mounted Samba (SMB) shares, I hope this helps:
We were able to mount a test share on a remote LAN server via SMB, and share the root of that mount with a remote WAN server via Syncthing. We used a share containing the contents of the Office 2007 CD, 512MB or so. Syncthing created an .stfolder directory in the root of the share (so Syncthing would need to have write perms to that via the share). When we manually disconnected the SMB mount, Syncthing noticed the change and stopped the folder, with the message, “Stopping folder [folder name] - folder marker missing.” I.e. it did not start deleting files on the remote WAN server. Eventually the remote WAN server found that the sources were missing and reported itself Out of Sync. Thus it is possible to sync shares mounted via samba using Syncthing. There was one drawback: each time the rescan period expired, the remote WAN server spammed over 2000 lines into the log file. With a rescan period of 60s this would create a very large log file pretty quickly.
@JinxGenius Maybe read the use case again: There IS a Syncthing service on each end - the LAN and the WAN. In our case, the WAN does not have access to the Samba sources (naturally). Additonally, we wish to run Syncthing on a separate internal machine for various reasons. Regardless, the question was, how would Syncthing handle mounts that are prone to just disappear. This applies to USB mounts as well. Our post is intended to illustrate that Syncthing will correctly handle that case by stopping the sync, rather than thinking that all the files have been deleted.
So this safeguard has drawbacks. If you mount a folder within a syncthing folder, that will still look like the files are deleted. Also, looking at open tickets, I think there exists some edgecases where files do get deleted, but we never found a reproducible case to patch it up.
This is the “no source device available” stuff? It’s a bit unfortunate. The root cause is that the WAN server (with the missing disk) has announced files that the other device wants, but then can’t provide them when asked for them. Possibly we should move a few of these errors to debug level now that they are also accessible as “failed items” in the GUI…
Will let you know if I ever run into a case where files go missing.
@calmh Just to be totally clear (and for the help of anyone reading this who is thinking of using Syncthing with mounted drives): It’s actually the LAN server that has the missing disk, not the WAN server, which I think is what you meant. But it was the WAN server that generated the log file lines. Here’s the setup: Syncthing1 mounts the SMB share and shares it to Syncthing2, like so:
