Tim77

I'd love to have a native Chromebook app for resilio sync. A PWA would be awesome. To be fair, the Android app works well enough on Chromebooks that support Android, but a native app is always better, IMO.

2.6.3 was way too buggy for me. I'm sticking with 2.6.2 until they release a stable upgrade.

This is a good guide: https://help.resilio.com/hc/en-us/articles/206178924-Installing-Sync-package-on-Linux Bascially, you can add the rslsync user to the pi user's default permissions group (pi), like this: sudo usermod -aG pi rslsync You will also have to change the permissions on the pi home folder to allow read/write permission for the pi group: sudo chmod g+rw /home/pi

Version 2.6.2-1 is working with this system, so I'm staying with it. There does seem to be a problem with 2.6.3-1. For the record, this is: Odroid N2 Ubuntu 18.04.2 LTS (GNU/Linux 4.9.170-27 aarch64)

I tried starting over using version 2.6.2-1 instead. So far, this is looking stable, but i haven't pushed it that hard yet.

Does this help? I'm seeing it repeatedly in the log: [20190508 21:50:11.856] TRACKER[66.165.233.194:4000, [2604:4500:9:58::10]:4000] closing connection to 66.165.233.194:4000/uTP[0x0000007f5c02ba60] - reason: EOF, error: 32770 (Tracker connection is closed by server) [20190508 21:50:12.001] Got response from "config.resilio.com" - message: "{"relays": [{"addr": "66.206.5.74:3000","addr6": "[2604:4500:3:80::10]:3000"},{"addr": "66.206.5.74:3001","addr6": "[2604:4500:3:80::10]:3001"},{"addr": "66.165.255.194:3000","addr6": "[2604:4500:8:24a::10]:3000"},{"addr": "66.165.255.194:3001","addr6": "[2604:4500:8:24a::10]:3001"}],"trackers": [{"addr": "66.165.233.194:4000","addr6": "[2604:4500:9:58::10]:4000"},{"addr": "23.111.157.86:4000","addr6": "[2604:4500:5:245::10]:4000"}]}", error: 0 (<NULL>), http_code: 200 [20190508 21:50:13.779] CoreState: removed error - code: 11, message: "There's no connection to tracker" I've verified that outgoing ports 4000, 3000, and 3001 are open.

Sync is failing on my new Odroid N2, running resilio-sync_2.6.3-1_arm64.deb on Ubuntu 18.04. History: For years I've run sync on a Raspberry Pi, with just the occasional hiccough. My setup is that the synced folders all exist on a BSD machine that shares them with the Pi via samba. Unfortunately, network speed on the Pi is too slow, so I upgraded to an Odroid N2 with the same samba sharing configuration. I followed the instructions here: https://help.resilio.com/hc/en-us/articles/206178924-Installing-Sync-package-on-Linux. Sync is running under the rslsync account and I've made sure that this account has all rights on the shared folders. Here's what happens: I can add all my folders to the sync identity on the Odroid and they all index successfully. The problem starts when I share these folders with other devices. The first few shares seem to go OK, but as I add more devices, I noticed in the logs that sync would finish syncing up that device and then go into a crazy loop would where it would basically initialize itself over and over. After many cycles of this it would seem to stabilize. However, when I added the last few of my devices. It would not stop looping and now consistently dies with these final entries in the log: [20190506 23:58:18.845] Debug log mask has been set to FFFFFFFF [20190506 23:58:18.846] Features mask has been set to 0 [20190506 23:58:18.848] ZIP: Can't locate [version] in zip, error -100. [20190506 23:58:18.849] Configuration from file "/etc/resilio-sync/config.json" has been applied [20190506 23:58:18.876] test sha1: AE5BD8EFEA5322C4D9986D06680A781392F9A642 [20190506 23:58:18.876] test sha2: 630DCD2966C4336691125448BBB25B4FF412A49C732DB2C8ABC1B8581BD710DD [20190506 23:58:18.877] test aes: 0A940BB5416EF045F1C39458C653EA5A07FEEF74E1D5036E900EEE118E949293 [20190506 23:58:18.877] DISKIO[0x00000055951d3bb0]: Create diskio pool for drive with id 18446744073709551614, path: , type: 0, size: 1 [20190506 23:58:18.877] WORKER[0x0000005595153e50]: created [20190506 23:58:18.877] DISK_WORKER[0x0000005595153e50]: diskio thread start, drive_id = 18446744073709551614, priority = normal When this dies, you can see that the sync process is still there: odroid@odroid:~$ ps aux|grep resilio rslsync 5282 0.0 0.1 172256 6592 ? Ssl May06 0:00 /usr/bin/rslsync --config /etc/resilio-sync/config.json odroid 7847 0.0 0.0 2704 644 pts/0 S+ 16:17 0:00 grep --color=auto resilio odroid@odroid:~$ But it doesn't respond to systemctl stop and the only way to shut it down is to kill -9. I tried tearing it all down and starting over and the same thing happens.

If you have a chromebook that supports Android apps, try the Resilio Android app. It works great for me. The only downside is that you get the Resilio mobile experience rather than the superior desktop experience, but it's good enough. I doubt that we'll ever see a native Chrome app, unless Chromebooks get a much bigger market share.

It's definitely an issue. Let's face it; selective sync as implemented is just a clever hack. Unfortunately, it's clear that Resilio has no intention of making it work properly, so I find that it's really not very useful for my applications. I end up doing only full syncs of very specific and and relatively small folders. Not ideal, but it is what it is.

You haven't addressed jrlacharnay's problem at all. This is a serious deficiency in selective sync and makes the feature much less useful to me and I'm guessing others. I have an NAS with terabytes on it. Full sync mostly isn't an option. Selective sync would be perfect if it worked the way I think it should but the way it handles deletes is not only unsatisfactory, but unintuitive. In other words, when I make a selective sync, I expect all aspects of sync to work on that selection, including deletes that propagate back to the connected machine. The answer of deleting the file in the Sync app instead of doing a normal OS delete is unworkable. Imagine working through a photo folder with a 1000 files in it. It's a huge waste of time to have to flip between the OS folder and the app every time I want to delete a file, not to mention error-prone. I really hope Resilio rethinks this.