• Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by iswrong

  1. I experimented with SyncThing half a decade ago or so. The issue for me with SyncThing is the sharing model, it's oriented around devices and device keys, rather than folders and folder keys as in Resilio Sync. SyncThing is great when you have two or more devices where you want to keep folders in sync. But it is not a great replacement for Dropbox shared folders or links, where you want to do quick ad-hoc sharing of random folders with random people. Resilio Sync is also inferior [1] to Dropbox for that use case, but miles and miles better than SyncThing. [1] E.g. case where I share a folder between my own devices and then want to share a subfolder of that folder separately with someone else, has all kinds of annoying limitations.
  2. Yep. The only announcement was a post by a Resilio employee on this forum:
  3. My wife and I have used Resilio Sync from the early 1.x days. I was even in the private beta group for some time. However, we are now planning a move off Resilio Sync. It's encouraging that there is a Mac build, but other than that it seems that Resilio Sync is largely dead. Maybe they are working on a big new version, but I find that highly unlikely. Even when the Resilio folks were working on new feature releases, there used to be regular bugfix/stable releases. My guess is that Resilio Sync is only a small market nowadays. Most people use cloud services and those that want peer to peer sync have largely settled on SyncThing. Resilio Connect offers a enterprise-wide solution and results in larger bulk license sales + probably less support per license. Of course, the question is where to go? SyncThing is pretty much out of the question for us, since it's not something that you can ask non-savvy family members and friends to install. Dropbox was robust and fast (if a cloud solution is possible), but the client has a large amount of feature creep, upsell nonsense, etc. Though, there is a pretty large chance that we'll land on Dropbox anyway, since they have a family plan now.
  4. The version offered on the download page: Is now a universal binary.
  5. @kos13 thanks for the update! I think keeping Sync minimal and aiming to make it as reliable as possible are probably the best possible goals for something like Sync. I think the problem that people had, was that there were very few signs of life and were worried that Sync might soon go away. If things look that way, people will stop recommending Sync to others, prepare a migration path, etc. I think just having regular bugfix releases would go a long way of taking away concerns. I believe that Sync still has a much better and more user-friendly sharing model than the most frequently mentioned (open source) competitor. So, I hope that Sync will stay with us for a while. As you say, Connect is the primary source of money, but at least I'd think that Sync is sort of a 'gateway drug' that for people to get to know Sync and later recommend Sync or Connect at work. Anyway, thanks for the new release, and... Likewise!
  6. Awesome! Thanks for putting out a new release. The macOS menu bar finally works again 👍. Looks like there are many other useful fixes and additions.
  7. It's a relief to hear that @kos13, good luck with the changes!
  8. This is false. Staff like RomanZ used to be active on the forums. I am still sure that Resilio is fine, even if they had cashflow problems, the technology is pretty valuable, so it is likely that they could be acquired if needed. But I wouldn't be surprised if the consumer-level desktop client is deprioritized. The desktop client ha[sd] a hard-core following, but I bet that a large chunk has always used free sync. Over time, they have segmented their product offering and it is likely that they saw a large majority of income coming from large(r) business users. Of course, this is conjecture like any other post. Agreed!
  9. Another possibility is that they are refocusing on enterprise-only (Connect). At any rate, this topic is two weeks old, if they'd wanted to end the worries, they would have replied to this topic by now.
  10. I don't think it is a good security practice to give sync blanket group access (unless you want sync to backup the complete user account). On most Linux distributions, the primary group of a user is unique (e.g. a user 'john' would be in the group 'john'). If you use a modern filesystem, you could use access control lists to give sync access to specific folders. See 'man setfacl', something like the following should do the trick: setfacl -d -m user:rlsync:rwx somedir The '-d' flag makes the ACL a default ACL for the directory (so that the ACLs are inherited by files created in somedir). That's easy to do with systemd. I have once written up the configuration here: 'btsync' just becomes 'rlsync'.
  11. Did you try to connect to localhost:8888 or ? By the way, you don't need remote X to connect to the GUI, you can just use SSH port forwarding and use a local browser. E.g.: ssh -L 8888:localhost:8888 yoursever.tld This will forward port 8888 of the server yourserver.tld to port 8888 of your local machine. Then you can just browse to localhost:8888 on your local browser.
  12. There is no proxy. Only a tracker that is used by peers to announce what folders they have. From that point on, communication is end-to-end. A relay server is used if end-to-end communication is not possible. It used to be the case that RLSync could also operate without Resilio's trackers by using the DHT, but the use_dht option was removed at some point.
  13. When using standard folders, RLSync derives a folder identifier from the secret key (this is completely safe due to how cryptographically-secure hash functions work). Your peers announce the availability of the folder using Resilio's trackers and/or DHT (IIRC DHT support has been removed some time ago). Your peers find each other through the tracker and communicate directly end-to-end (if possible). If there is some NAT + firewall between the devices such that an end-to-end connection is not possible, RLSync will use Resilio's relay servers. Both devices will connect to the relay server and communicate through the relay (which only sees encrypted data).
  14. Is there are difference? The size of the unencrypted and encrypted data is approximately the same (plus padding, etc.). If you are asking whether encryption could be the bottleneck, then this could indeed be the case. There are two ways you can find this out: Check the CPU usage of Sync during transfer. Disable encryption on the LAN. This is controlled with the lan_encrypt_data option: I am not sure if Resilio Sync uses AES-NI. If it does, it is unlikely that encryption is the bottleneck on a modern CPU (assuming that both ends support AES-NI instructions).
  15. Did you check CPU usage? Maybe the source machine is spending most of its time encrypting data? If that is the case, you can try to set the lan_encrypt_data option to false in the power user preferences.
  16. The encrypted folders work differently than you think. They give you an extra folder key. When this key is used on a RLSync instance, it becomes a peer for the folder, but this peer will not be able to decrypt the data. The typical usage scenario is when you want to use a VPS in the cloud to be a peer, but you cannot trust this VPS (e.g. because the cloud provider can seize and turn over the VPS, the VPS could be hacked, etc.). Using an encryption read-only key, the VPS can contribute bandwidth without being able to read the data. Even if you use an Encrypted folder, the folder is not encrypted on peers that have read-write or read-only access. Only data in transit is. If you want to protect data on devices with read-write or read-only access, you'll want to use full disk encryption. Whether encryption of an SD is supported depends on your Android version (and probably manufacturer). Unfortunately, full disk encryption is in a bad state on Android. Personally, I wouldn't store sensitive data on an Android phone.
  17. I think Vince42 is referring to the web interface here and wants to use a Let's encrypt certificate rather than a self-signed certificate, which is completely reasonable IMO. Vince42: I assume that you are requesting the certificates while using Apache/nginx/... to do the validation? I think there are two reasonable approaches to do this without copying or changing ownership: Create an extra group, of which both your web server user and RLSync user are a member. Give the group read access to the certificate; or use filesystem ACLs to configure more fine-grained access rights (with ACLs e.g. the www or apache user could be the owner of a file, but the RLSync user could also have read access).
  19. Did you try Bittorrent Sync outside the chroot? Also, are you sure that the CPU has hardware floating point support (the Cortex-A9 has an optional FPU)? (You could try to run some other binaries in the chroot environment.)
  20. Resilio Sync does work over the internet. Does the information for the folder show any peers?
  21. I looked at the Mac client and the largest change is in (the web UI). Within that file, it seems that some large images (GIFs) are added for a/the selective sync tutorial. They are animated GIFs that are shown when enabling selective sync and clicking on the question mark icon.
  22. Is this an artificial limitation (e.g. to avoid Sync being used for illegal file sharing) or a technical one? (Sync's relay servers or trackers wouldn't be able to handle the load.)
  23. But Dropbox is also not for backup ;). File synchronization is in general not fit for backups. Any 'damage' is propagated everywhere, old versions are removed after a while.