jdrch

This has been discussed elsewhere in the forums before. The Android client was updated as recently as last week. I haven't experienced any bugs I haven't been able to work around across Windows, macOS, Android, Linux, and iOS peers. I don't personally need any new features.

See Step 13 here. Remove sudo from the systemctl --user enable command and you should be just fine.

@USFreedom2021 Are you installing the latest build? Which SKU and version of Windows are you trying to install this on?

Yw!

Sync works just fine for me on 4 Android clients (Google Android, Samsung One UI, and LineageOS.) On Android: Ensure Sync has folder read and write permissions for the synced folder, especially if that folder is on a microSD card. Without that, syncing will fail. The foolproof way to deploy Sync (assuming you're a Pro user with an identity already set up) is this: Select a source folder. The folder may be empty or may have files in it. If it has files in it, wait for Sync to finish hashing them before adding any peers Add peers for that folder. Although official Support says destination folders don't have to be empty initially, in my experience it's best that they are empty Choose the sync type you want (Selective On or Off) Wait again for the initial sync to complete (especially if Selective Sync is off) Once the above is done, you can add files to or remove files from the synced folder on any peer and the changes will show up on all peers (as fast as their respective network connections allow the changes to be transferred.)

UPDATE To be clear, I do not have any information about point 3 of the following specific to Resilio Sync. Several things: Most of Resilio's staff are in Belarus To put it mildly without getting political, Belarus has been experiencing significant political upheaval recently Minsk's startup hub was just shut down by the government So it doesn't seem to be very pleasant times for tech in Belarus, not mention the global pandemic is still a thing. My guess is, not only is the political situation not ideal, the government is probably also closely monitoring and or restricting the population's internet use and access. This, in turn, would affect the ability of staff to develop the product, respond to bugs, and participate on forums. ____ The apparent lull in activity has happened before. The project wasn't dead then and it certainly isn't now. If you reply to that thread (the longest of its kind on this forum) you may get some attention since devs are on it. I disagree strongly about Syncthing, at least for the platforms I use and my workflow. For example, Syncthing for Android still can't write to microSD cards (something Resilio Sync has been able to do from day 1) in 2021. My Note9 has a 400 GB microSD card I sync data to and from, so that's a critical feature to me. As a heavy Resilio Sync user (it's the backbone for my workflow) across Android (arm64), Windows 10 (amd64), Ubuntu (amd64), Debian (amd64), Raspberry Pi OS (arm64), and FreeBSD (amd64) (11 devices total), I'm not aware of any bugs at all. Follow the extensive documentation and/or search the forum and you should be fine. The most common difficulty I see is people trying to sync multiple large folders with different content. The best way to do that is put all the content you want in one folder and sync to an empty target, as well as ensure any new folder used to connect to an existing folder be empty upon initial connection. But by all means use what works best for you. If that's Syncthing, then use Syncthing.

Yes it is. The Home Pro product has been feature complete/stable for a while now and so mostly sees bugfixes in response to host OS changes. Understandably, these are much less frequent than new feature drops. Speaking as a longtime Home Pro user (since 2014). I would not suggest paying for a license unless doing so gives you a feature you need and the free version doesn't have. The reason I say this is the exact reason you posted: license fees are best thought of as covering features, not development. Ergo, paying for the latter might set up you with false expectations of frequent releases or platform/ISA support. This topic has come up in the past; although there has been no official word on it, my take is that benchmarks show x86-64 apps running at native speed on M1 Macs. Unless you use 10 Gb/s or faster networking or some super high performance Thunderbolt storage array I doubt you'll see any performance difference. FWIW there's no Windows Arm64 build either; and WoA machines have been around for much longer than M1 Macs have. _____ Side note: Don't get anxious about the development status of a product that has seen a version release within the past year. There are many excellent paid storage software related products that probably get 1 or 2 releases (or fewer) per year, e.g. DrivePool, Don't be alarmed because something hasn't been updated within the past month. The only time you should worry is if the dev's compatibility docs/system requirements don't mention/include the latest major release of the OS you're running on OR if there a bunch of critical open bugs. For example, an app that lists Windows 7, 8 (no mention of Windows 10) would not be one I would use.

Thanks! I wonder if this is possible for Windows also ...

CAVEAT: The solution below assumes you don't want to run Resilio Sync under the rslsync user profile. I suppose it can be modified for those who do want that, but I don't currently have any instructions to that effect. Since running under rslsync is Resilio Sync's default behavior, I believe simply following the official setup documentation will get you there. This fix worked on a fully patched and updated Debian Buster system on the calendar week of this post's writing. If Sync is loading with no profile: 1) Shut down (not restart) the computer 2) Start the computer. 3) On boot, check that the Sync instance with the existing profile has loaded. Load the web interface and note which port it's running on (the "nnnn" after the ":" in the browser address bar. The value is usually 8888) If it has, proceed: 4) Run the following: $ ps aux | grep rslsync | grep -v grep This should give you a list of rslync (Resilio Sync) processes currently running: $ ps aux | grep rslsync | grep -v grep YourUsername 1213 2.4 1.8 1554204 305756 ? Ssl 09:13 0:24 /usr/bin/rslsync --config /home/YourUsername/.config/resilio-sync/config.json rslsync 17678 0.0 0.1 972796 29900 ? Ssl 09:30 0:00 /usr/bin/rslsync --config /etc/resilio-sync/config.json Now you know there are 2 rslsync processes running: one under YourUsername, and the other under rslsync. But which one has the existing profile (read: is driving the web interface)? The next step answers that. 5) Run the following command to list all processes using the port 8888 (the port the correct Sync profile from Step 3 is using): # lsof -i :8888 This should give you an output with a single entry: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rslsync 1213 YourUsername 50u IPv4 36915 0t0 TCP localhost:8888 (LISTEN) The instructions from here on assume the output of the above under the USER column is YourUsername. If it's something else, a modified approach not covered here may be necessary. Now that we know the correct profile is running on YourUsername, it's time to figure out which profile or user the Resilio Sync service is using: 6) Stop the Resilio Sync service: # systemctl stop resilio-sync This will kill 1 of the rslsync processes from Step 4 7) Repeat Step 4: $ ps aux | grep rslsync | grep -v grep YourUsername 1213 1.8 1.8 1636556 309544 ? Ssl 09:13 0:47 /usr/bin/rslsync --config /home/YourUsername/.config/resilio-sync/config.json As you can see, the Resilio Sync process under the rslsync user was killed in Step 6. This means it's the Resilio Sync service is running under rslsync, which is undesirable for our purposes. 8 ) To confirm the previous step's finding, start the Resilio Sync service: # systemctl start resilio-sync 9) Repeat Step 4: $ ps aux | grep rslsync | grep -v grep YourUsername 1213 1.8 1.8 1636556 309544 ? Ssl 09:13 0:47 /usr/bin/rslsync --config /home/YourUsername/.config/resilio-sync/config.json rslsync 14130 7.0 0.1 890604 20108 ? Ssl 09:57 0:00 /usr/bin/rslsync --config /etc/resilio-sync/config.json The rslsync Resilio Sync process has reappeared upon starting the Resilio Sync service, which means the service is currently running under rslsync. We want to both switch the service to run under YourUsername AND ensure Resilio Sync processes don't automatically launch under rslsync. 10) Repeat Step 6 11) Disable the Resilio Sync service: # systemctl disable resilio-sync Synchronizing state of resilio-sync.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable resilio-sync Removed /etc/systemd/system/multi-user.target.wants/resilio-sync.service. Of note is the "multi-user.target.wants" in the above. It confirms that Resilio Sync is current configured to run under multiple users, which is not what we want. 12) Repeat Step 4: $ ps aux | grep rslsync | grep -v grep YourUsername 1213 1.8 1.8 1636556 309544 ? Ssl 09:13 0:47 /usr/bin/rslsync --config /home/YourUsername/.config/resilio-sync/config.json As you can see, stopping and disabling the service did not kill the Resilio Sync process running under YourUsername (anyone want to explain why? I'm not sure myself. If the process under YourUsername isn't controlled by the Resilio Sync service, how is it starting automatically at boot?) 13) Follow the official setup documentation on editing the corresponding systemd file so that the Resilio Sync service uses YourUsername only: Do not run the last command as root or using sudo, as it is intended for your account, not root, and so will throw an error message, such as: Failed to connect to bus: No such file or directory On some distros, such as openSUSE, you will also need to run the following command to explicitly start Resilio Sync under your username: $ systemctl --user start resilio-sync 14) Repeat Step 4: $ ps aux | grep rslsync | grep -v grep YourUsername 1213 1.8 1.8 1636556 309544 ? Ssl 09:13 0:47 /usr/bin/rslsync --config /home/YourUsername/.config/resilio-sync/config.json Resilio Sync is now running as intended under YourUsername only. I believe this should persist across reboots, shutdowns, and kernel updates. Thanks Alex Witz from Support for the commands and ideas.

UPDATE: See OP for solution. Pi-Hole allowed it. I fixed the issue, actually. Just need to write up a solution so others can benefit. Unfortunately today is extremely busy and I'm behind in a technical training session because I was resolving this issue during the lecture.

UPDATE: Fix. The problem was Resilio Sync was running under multiple users and so the process that didn't have access to the web interface was apparently freaking out. The above is happening to the latest Debian build on a fully updated Debian Buster system. It shouldn't be happening. Any idea what's going on?

Ah, well that's odd. There may be some closed source kernel modules you can try loading, but I don't know which ones match that NIC specifically. Ask at the places I mentioned earlier.

Are you using Intel, Mellanox, or Chelsio NIC(s)? FreeBSD frequently has trouble with NICs that aren't 1 of those 3. My FreeBSD has a Realtek NIC and the wired connection crashes every now and then.

Fair. The only reason I run FreeBSD is so I can accurately comment on all major OS families (except macOS, which I'm planning to add sometime this year) from firsthand experience. OSes are a hobby of mine. However, I ran into the same frustrations you are with FreeBSD, to the point of making a list of reasons why I might stop running it in the future. As for stability, I also run Debian and in my experience its the most stable useful OS I have on hand (the others being 3 release channels of Windows, Raspberry Pi OS, FreeBSD, OpenIndiana, Ubuntu, and Android.) I emphasize "useful" because OpenIndiana is also stable but the documentation, hardware support, and package support are so bad it's really not worth using for something serious unless you're migrating from Solaris and don't want to learn anything new. OI also doesn't support UEFI boot. In 2020. Yikes. As for virtualization, are you saying running FreeBSD as a VM is difficult, or that it's difficult to run VMs on FreeBSD? AFAIK bhyve is the preferred solution for the latter, and I've seen folks achieve the former using Proxmox. However, I have no personal experience with either solution. If I were in your shoes, I'd pick whichever OS works best for what you want and just run the other on used/less important hardware. That way you can keep up with developments without having to dogfood them. But that's just me. Cheers

We may just be arguing semantics here, but technically I don't think my implementation is a service in the FreeBSD sense of the word. It's a background process that starts at reboot explicitly from a crontab entry. A true service is managed by FreeBSD init, which quite honestly I've spent years trying to understand - at least for apps like Resilio Sync that are delivered as FreeBSD binaries and not packages - to no avail. The other problem with setting up the binary as a service is - IMO - it makes updating it a much bigger PITA, because now you have to tangle with manually stopping and starting the service instead of just killing and then launching the process.* I have no actual idea how to set up a FreeBSD service from scratch using only a binary; I've never been able to find any documentation that explains it fully and the FreeBSD Handbook is almost incomprehensible on the topic. Ironically, I got my method from the Handbook itself, which admits that it's easier in most cases to use crontab to get something to start at boot without user interaction. If you're able to figure it out, please by all means share it with me and I'll add it to my writeup. IIRC one thing you'll want to look into is your user rc.d directory. I do believe that's where services that run under users live, but I'm not 100% sure. You can also ask at r/freebsd, r/bsd, or the FreeBSD forums. Sorry I'm not able to be of further assistance! *Soapbox: This is why I laugh when folks complain about systemd on Linux. Systemd is the greatest thing to happen to Linux ever, because it makes service management much less of a barely comprehensible CF as it is with init (as you're experiencing now). Services.msc (Windows) is still the best service management system in existence, period. Click to stop, start, restart, disable, enable, set to manual or automatic, etc. all through a single UI.