• Content Count

  • Joined

  • Last visited

  • Days Won


About iswrong

  • Rank
    Advanced Member

Recent Profile Visitors

819 profile views
  1. It's a relief to hear that @kos13, good luck with the changes!
  2. 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!
  3. 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.
  4. 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'.
  5. 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.
  6. 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.
  7. 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).
  8. 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).
  9. 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.
  10. 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.
  11. 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).
  13. 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.)
  14. Resilio Sync does work over the internet. Does the information for the folder show any peers?