iswrong

Note that deleted files will only be archived on other peers. In general, you should use Sync (nor Dropbox) for file synchronization and not backups for many different reasons, including: You might find out about some file being deleted after 30 days. The archive is too crude to use for long time periods (every change creates a copy, rather than storing incremental copies). It's very hard to reconstruct a directory snapshot of a particular date from the archive. The archive does not store any extra metadata for validation (e.g. checksums). If your peers are all in the same premises, theft, fire, thunder, or water damage might destroy all your peers with their data at the same time. When a file was not synced to other peers for some reason (e.g. because they were down, or because of a software bug), removal will not put the data in any archive. Use incremental backup software for backups, preferably off-site, etc.

Did you consider buying a somewhat beefy x86_64 box and using something like FreeNAS? (Or a Linux-based NAS distribution?) I think hardware-wise this is often a better trade-off than a real NAS and it gives longer support cycles. Of course, it may be a bit more work when it comes to administration.

You can sync any directory, including directories on external disks. But this sounds like illegal distribution :(.

Do you have selective sync enabled on the folder?

I would think (but didn't check) that Sync would exit gracefully when it receives a SIGTERM signal. (As in: the sync may not be complete, but everything is in a consistent state.)

Also, doing this introduces races. What if a file starts syncing in a directory while you are checking for temporary files. Did you consider stopping/starting via your init system?

But this only talks about attacks on a specific folder. The topic starter is interested in the probability of colliding with any folder key and possible mitigations.

Agreed, even if it is in permissive mode by default with instructions on how to make it enforcing.

I fully agree. Though, I think in practice this could lead to some problems: Debian does not run AppArmor by default (only Ubuntu). If the user is not aware of AppArmor, they might have troubles using Bittorrent Sync. Bittorrent Sync can also be used as a normal user (there is a systemd unit file for this), this would require different AppArmor profiles. That said, I use the following profile: #include <tunables/global> /usr/bin/btsync { #include <abstractions/base> #include <abstractions/nameservice> / r, /etc/btsync/config.json r, /etc/issue r, /etc/passwd mr, /home/ r, /home/*/ r, /home/btsync/ rw, /home/btsync/** rw, /run/btsync/btsync.pid rwk, /sys/devices/** r, /tmp/btsync_dumps/ w, /var/ r, /var/lib/ r, /var/lib/btsync/ r, /var/lib/btsync/** mrwk, } (I have created the /home/btsync directory to store folders.)

You can share a folder between different identities, so: create a new identity on the second computer, create a folder (either standard or advanced) and add it to the Synology (under the existing identity). Since the first computer and the Synology are under the same identity, the first computer will see the folder of the second computer. You can leave it disconnected, so that it does not get synced. (Or you could give the first computer it's own identity as well.) Ps. Sync is not a backup tool: a deletion of a file removes the file from all machines and by default deleted files are only retained for 30 days. So, you'll either want to set the archive retention time to unlimited and/or use an incremental backup tool.

Warning: I am not a cryptographer, so this might be wrong. Standard Sync folder use 160-bit of random material. Brute forcing a specific folder is virtually impossible, because it is a search space of 2^160. We can use the birthday paradox to find out when we expect a collision, the birthday bound is 2^(n/2), so we expect a collision when 2^80 folder keys are generated. In other words, every member of the world population needs to have 1.633684e+14 folders before we expect a certain collision. Obviously, the key space is very sparse, so you'd have to do many more than 2^80 attempts to find a collision. Moreover, finding a collision has two complicating factors: For every generated key, you need to query the DHT, which has quite a lot of overhead for brute-forcing. BTSync sends a derivative of the key to discover peers. Even if you find a collision of the folder ID, it does not mean that you have found an in-use key. I am not sure if nodes that participate in the DHT apply rate limiting. But even if they don't, the attack that you mention seems impractical. Though it would be nice if one of the Resilio cryptographers can weigh in.

Ah. I had this issue on Linux ARM with glibc and a read-write root filesystem. This may be a bit more work on such a constrained environment. Another thing you can try (except for hoping that Resilio creates a package) is to update the dynamic linker path in the btsync binary to /lib/ld-uClibc.so.0. You can do this e.g. with patchelf: https://nixos.org/patchelf.html Of course, it will probably be hard to do this from the NAS, but you could do this from another Linux machine and copy the patched binary to the NAS. Some Linux distributions (e.g. Debian) have patchelf in their repositories.

You typically get this error when the dynamic loader cannot be found. Sync (on ARM HF) expects /lib/ld-linux-armhf.so.3: % file btsync btsync: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped ~/Downloads/sync % strings btsync | grep lib.ld- /lib/ld-linux-armhf.so.3 If this file is not present, you have to find the path of the dynamic loader and symlink it: % find /lib -name 'ld-linux*' <dynamic loader path> % sudo ln -s <dynamic loader path> /lib/ld-linux-armhf.so.3 Then the 'No such file or directory' message should go away.

As Jammin says, if you only sync on a LAN, the bandwidth use is very limited. Assuming that you keep the normal configuration, it will do some WAN communication for contacting trackers and the DHT. You an also set upload/download bandwidth limits. If you are worried about WAN communication, you can also set up Sync to use LAN only: https://help.getsync.com/hc/en-us/articles/204754349-Can-I-force-Sync-to-do-local-network-LAN-syncing-only-and-not-sync-via-the-Internet-

Indeed, you have to recreate the folder. When both folders are not encrypted, you can avoid the initial sync by moving the files from the old folder into the new folder. However, this is not possible with an encrypted folder. Unfortunately, this is not the case. The key structure for keys supporting encrypted peers is different. Keys that do not support encrypted nodes: RW key: starts with an 'A', followed by 160 bits of random data encoded in base-32. RO key: derived from the RW key by an RW peer, starts with a 'B'. This secret is required to participate in the swarm to receive/share data, but is not enough to write data. Keys that do support encrypted nodes: RW key: starts with an 'D', followed by 160 bits of random data encoded in base-32. RO key: derived from the RW key by an RW peer, starts with an 'E'. However, compared to keys that do not support encrypted nodes, it's twice as long. The reason is that it actually consists of two secrets: the secret to participate in the swarm and the secret for encrypting/decrypting data. Encrypted RO key: this consists only of the 'swarm participation' part of the RO key, and misses the data encryption/decryption secret. Starts with an 'F'. As you can see, the migration would not be trivial, because it would involve redistributing new keys. This could bring the whole swarm in an inconsistent state if some nodes are offline for a longer time period. The new advanced folders were invented exactly for this reason, since they rely on identities rather than shared keys, it's possible to change permissions on the fly. Unfortunately, encrypted-only sharing is not yet supported for advanced folders.

Sync for Workgroups (needed for business use) is a subscription that costs $39.99 per year. Sync Pro for individuals is a perpetual (lifetime) license, including free updates for Sync 2.x versions. Don't know why it bills you $15 :).

Works fine for me. Did you connect to the right port? Did you check with 'netstat -tap' on which ports sync is listening?

Did you try update-rc.d ?

Did you try to add the script to the correct runlevels? sudo update-rc.d btsync defaults Since Ubuntu 15.10 has systemd, you can also use the systemd unit to automatically start Sync: sudo systemctl enable btsync

There were some problems with the getsync.com domain yesterday, I saw the same error on one of my machines. It can take some time before changes are propagated. What solved the problem for me, is temporarily switching to another DNS server. (E.g. Google public DNS: 8.8.8.8, 8.8.4.4)

Indeed, luckily only two more months ;).

Yes, that's how it currently works. Syncing a folder is just a one-time request to sync all files in that folder (or subfolders). It's not 'sticky' in the sense that new additions to that folder get synced as well. The behaviour of Sync differs from that of Dropbox et al., in this respect.

Where do you get this error message? Did you to set the directory_root configuration option in sync.conf to /mnt/data?

It's for logging on to the web interface. When there are multiple users on a machine or when you bind the web UI to some 'external' interface (so, not the loopback interface), you'll definitely want it for security.

Just for reference (since there seem to be suggestions to the contrary in another thread). It's also easy to run the official package using different users. Install the official package. Install systemd. Create the file /etc/systemd/system/btsync@.service: [Unit] Description=BitTorrent Sync for %i [Service] Type=simple User=%i ExecStart=/usr/bin/btsync --nodaemon --config /home/%i/.sync/sync.conf WorkingDirectory=/home/%i Restart=always [Install] WantedBy=multi-user.target You can now create a configuration file for your user in /home/<youruser>/.sync/sync.conf . There are some instructions in this blog post on how to do this: https://danieldk.eu/Posts/2015-10-18-erp.html (look at the 'per-user configuration' section). You can now start/stop/restart and permanently enable the service for a specific user: sudo systemctl start btsync@<youruser>.service sudo systemctl stop btsync@<youruser>.service sudo systemctl restart btsync@<youruser>.service # Get the status for the service sudo systemctl status btsync@<youruser>.service # Permanently enable sudo systemctl enable btsync@<youruser>.service The nice thing about this approach is that it works for any number of users, just fill in the user name in the <youruser> part. E.g. our Raspberry at home has BTSync instances running for me and my wife, under different users.