Use case recommendations (three way sync, two OSs on same machine, one CIFS share)

Support
1

Greetings,

I’m quite new to syncthing and am looking for recommendations about my use case. I dual boot at work and am looking for a solution to sync files between Linux, Win 7, and a CIFS share. From reading about syncthing, it appears it requires 2 machines on at the same time, which is where I’m struggling about how best to use syncthing (or even if I should).

I want local access to files from either OS, and if I’m on my corporate intranet (CIFS is accessible and mounted), I want that OS to sync to the CIFS share. When I reboot, I need the changes to propagate to the other OS.

Is this possible, or would something else be better?

Syncthing is typically described with respect to setting it up on a computer which would run the daemon… the CIFS won’t have this, though I’ve seen mention of two users on the same machine. So perhaps each OS needs to treat it’s local copy and the CIFS as separate user folders to sync?

I also considered rsync, but since I’m two-way syncing, think I’d run into challenges as I’d have to sync once from local -> CIFS and once the other way around (and what if a file’s local but not on the CIFS… delete it on the push from local, or add it on the push from CIFS?). Thus, syncthing seemed nice to take care of these two-way issues.

Lastly, I have a raspberry pi which I’ve considered using as an always-on peer with the CIFS mounted. Then I always sync to that, and when I boot up the other OS, it’ll find the RPi to sync with.

Hopefully this makes sense and apologies if this has been covered.

P.S. I can’t simply share a partition due to McAfee Endpoint Encryption. My solution has been to use an external SSD with TrueCrypt, but this is clumsy and annoying. I’d love to just keep local copies of my work files on both OSs, kept in sync somehow.

2

You can’t make this happen without having two devices online. If the files you are expecting to sync are large, you will struggle to do it rpi as encryption will just kill it. Also, as far as I recall CIFS also has some weird permission issues (you can search the forum about this).

3

But do they have to be online all the time? I guess I figured syncthing would kick in whenever two peers were online at the same time. I’d accept that if I worked locally on Linux, rebooted into Windows and edited the same file without Linux being able to sync to the CIFS first, that things could go awry, and I’m okay with that.

Would this latter use-case work?

If so, I think what I’d need direction on is how to have a local folder to sync, which treats the mounted CIFS like another peer. If it’s on, they sync, if not it doesn’t.

It would be like peers syncing to a separate repository, but never seeing each other online. I guess I’m treating this like github. It’s understood that if User A edits but doesn’t push and User B edits and pushes that User A will have some changes to merge next time he tries to pull.

Good to know regarding the Pi; while I have several large files, the vast majority of sync operations will be typical “work stuff” (text files, spreadsheets, pictures in the few MB range, etc.).

Thanks for the quick assistance,

John

4

So I’d mount the CIFS on the RPI and not mount it locally on the laptop, and then just have either of the OS’es sync with RPI using that as the always on device and the source of truth.

The dual boot machine would never see each other directly obviously.

5

Syncthing actually does not support syncthing “local” copies, i.e. a single instance managing two paths for the same repo.

You can either:

  • Run an instance of Syncthing also on the machine which has the CIFS, instead mounting it locally. Or use the RPi for this purpose.

  • Run two instances of syncthing locally (not recommended).

  • Try other solutions such as Unison.

6

Thanks for the input, all. Just to summarize the two options:

RPi as node

  • RPi always on with CIFS mounted and shared
  • setup syncthing on both OSs, adding the folder broadcast by the RPi

local method

  • keep a working directory on both machines
  • setup script/service such that if the CIFS is mounted, it will run rsync or unison from the local dir, pushing changes to the CIFS share

Torn on these… maybe the local sync is the way to go given my use case. From reading the other posts (thanks for those, by the way) it sounds like for local backup/sync, the complexity of syncthing isn’t really necessary. The primary benefit I saw was to automatically handle the two-way cases vs. having to run rsync twice to pick up changes from both a local instance and CIFS (which would have been pushed by the other OS).

That said, this is pretty much how I use the external drive anyway… if I need to access a file I need to make sure it’s on the external drive before I reboot (for example if I’d been working from a temp/Desktop folder). This would be similar – if I want to access/change it, I just need to be sure to run rsync first.

Thanks again, I’ll consider this as having answered all my questions!

7

That’s exactly the main difference between rsync (unidirectorional) and unison (bidirectional). Indeed, unison uses an incremental protocol similar to rsync:

Unison uses the ‘rsync algorithm’ for ‘diffs-only’ transfer of updates to large files. Setting this flag to false makes Unison use whole-file transfers instead. Under normal circumstances, there is no reason to do this, but if you are having trouble with repeated 'rsync failure’ errors, setting it to false should permit you to synchronize the offending files.

Moreover, rsync can be explicitly called from unison. See Making Unison Faster on Large Files in the manual.

In a very similar use case, I’m using syncthing to sync two devices. In one of them, I use unison to sync the repo with a partition and a shared drive. In the other one I use rsync for backups (rsnapshot).

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.