Local sync solution for small scale use⌗

Back in January 2019 I was on the hunt for a program that would let me keep a small shared folder in sync across all my local machines, that I could host myself, and that would not need to reach out to the internet to operate. That search led me to Syncthing and it is everything I needed and more. Thank you Jakob Borg (@calmh), Audrius Butkevicius (@AudriusButkevicius), Simon Frei (@imsodin), Tomas Cerveny (@kozec), and all other contributors to this project.

The instructions below were from my initial installation of Syncthing v1.0.0, though they have held true through all subsequent releases. As of this writing, version 1.2.0 was just released. All updates on my machines have worked flawlessly and I’ve yet to run into sync issues between my machines if a machine has lagged behind in updates. If you are following this in July 2019 or later, you should have no problems and I will do my best to update this post if subsequent releases change any of these instructions.

Syncthing allows you to keep files in sync across your machines, while keeping you in full control of where your data is and how it is transported. All machines running Syncthing will be assigned a Device ID which is used to uniquely identify machines in your setup and across the Syncthing network. The documentation has a great write up of how Device ID’s are calculated and how they are used which you can find here.

Machines can connect to each other directly on your network or relays can be used to move data from machine A to machine B (or more) through the internet. Relays are community maintained (listed here) and do not have access to your unencrypted data. Only encrypted data is moved through relays, though your IP address and your Device ID’s must be known to the relay for them to operate. At the time of this writing, relay support is enabled by default in Syncthing and your machines will reach out to register with the nearest relays on first run. This feature can be turned off if you wish to accomplish the same setup I describe below.

Here are the steps I took to setup Syncthing on my laptop (running Fedora), a container used as the master node (running CentOS 7), and on my Windows 10 machine. Let’s assume we’re setting these up simultaneously. Differences in Linux and Windows commands will be noted.

  1. Head to the Syncthing website and download the latest version for your machines architecture.

  2. Unpack the archive into a folder owned by your local user. On Fedora and CentOS tar -xzvf filename.tar.gz

    On Windows 10 right click on the zip file and select extract all, rename the new folder syncthing, then move this folder to the C:\ directory on your machine

  3. Run the Syncthing command to create the files necessary for encryption, your Device ID, and the initial sync folder used for file sharing
    On Fedora and CentOS ./syncthing

    On Windows 10 run the syncthing.exe program in the folder you just moved to the C:\ directory.

    Both systems should show the initial setup stages in your terminal and provide the port for the web interface on your local machine.

  4. Test the status on each machine by visiting 127.0.0.1:8384

    • If your master node is headless, forward this default port to another unused port on your local machine and confirm the status that way. I have a quick write up about this here
    • You should have three Syncthing nodes at this point; your CentOS 7 master node, your Fedora node, and your Windows 10 node

  5. Once confirmed working, we need to setup the machines to sync with each other. For our setup, you would:

    • From your Fedora machine, add the master node as a remote machine and share your default folder with it
    • Repeat on your Windows 10 machine, add the master node as a remote machine and share the default folder
    • Accept the share requests from both nodes on your master node, or add the Fedora and Windows 10 machines individually and share the default folder with them
    • Note: To make these systems local sync only, make sure to turn off NAT Traversal, Global Discovery, and Allow Relaying while adding these machines. When I set this up, I had an easier time specifiying the IP address and port (default 22000) of all my machines during setup instead of relying on the discovery service.

  6. Once all machines have been setup, confirm that the master is connected to and in sync with both the Fedora and Windows machines, and that both of those machines are connected to and are in sync with the master node

    • At this point, you should be able to save a file in the default folder of any machine and it will propogate out to the other two machines, reaching the master node first and then on to the other machine(s)

  7. Now that the system is working, you will need to set Syncthing to run at startup without automatically opening the status page in your browser.

    • On Fedora and CentOS:

      • Stop the Syncthing process

      • copy the Systemd Unit File (syncthing.service) from either the etc/systemd/user/ or etc/systemd/system/ folder included with the original files you download and unzipped, and place them into either:

        • /etc/systemd/system
        • /etc/systemd/user

      • enable the service with either

      • start the service with either

    If you installed Syncthing from the repository and cannot find the Systemd Unit File, you can grab it from their Github page from either the user or system directories

    • On Windows 10:
      • Follow the Start on Login section of the Windows instructions in the official Syncthing documentation.
      • It will have you create a batch file and place it in the startup folder for your user. That was the most fool proof method for me and I can’t think of anything to add to their write up.

  8. Step back and enjoy a local, cross platform sync solution that runs locally with the option to sync across the internet if you wish.

—– A Few Notes on This Setup —–⌗

This configuration with a master node and local only sync was something that I wanted, not how Syncthing is necessarily intended to be used. All data that moved through the relays would be completely encrypted but I always try to keep as much as possible from traversing the internet, especially when it isn’t necessary.

This setup accomplishes everything I was looking for, it is extrememly easy to add new machines to this setup, and if I ever wanted to utilize the relay feature it is only a few check boxes away. I mainly use this to sync text files (blog posts in markddown, dot files, zim notebooks) and a keepass database which are both handled very well and syync to the master almost instantaneously. On the few occaisions I’ve moved photos and other documents around, this system performed equally as well but I have not yet loaded it up with a significant amount of content.

—– Limitations of This Configuration —–⌗

  1. If working outside of my house, I have to remember to turn on my laptop when I get home so any new content is synced to the master machine. With relaying this would not be necessary, though I could also use my VPN connection to connect back home and stay in sync that way.
  2. If working on my desktop before I leave the house, I have to turn on my laptop and let it sync if I need the files I changed. If I’m going to connect back home through the VPN this isn’t a problem, but I’m not always headed to a location with internet access.

—– Additional Configuration Idea —–⌗

If you utilize the relays, the master node in our setup would not be necessary. It’s purpose here is to provide an always-on node that collects all recent changes so that the other machines, which are not always on, will sync the latest changes as soon as they are powered on and connect to the network.

One instance I can think of where you would want a master node and relays would be for version history. Syncthing allows you to retain versions of files if you choose. If you turned on versioning, you could delete on one node and when synced, the other node would move that file to a hidden folder and retain for the period you specified. Instead of collecting versions on each node, you could specify a master and only enable versioning there. Depending on how much you are keeping in sync and tracking, your master could have substancially more disk space to capture all of the versions, and your other nodes could retain only the latest versions.

References:⌗

Syncthing Getting Started Guide
Syncthing Autostart with Systemd
Syncthing Documentation - Relays