jdrch

AFAIK the only way to know is to connect to the folder and then look at the peers list. If you're worried about downloading everything from DCIM just by connecting, leave the folder in Selective Sync mode after you connect. That's why it's generally a good idea for your synced folders to have unique names. I sync my pics to my PC too, but I do that by using Tasker + Termux to copy my photos into a central, unique Sync folder that's shared among all my devices. Then, on my desktop PC, I import the sync folders from the \Sync folder to my photo library.

M1 Macs run x86 code just fine transparently via Rosetta 2 with very little performance penalty (or at least none that you'd notice in an app like Resilio Sync.) So just use what's already there.

Moving the .sync folder would not only be hacky, it could get really messy if you (or Resilio Sync) lost track of where the folder is. A better method is to disable archiving and versioning within Resilio Sync and use Volume Shadow Copy snapshots for that purpose instead. I have the same setup in which my Resilio Sync folders are also backed up to OneDrive, and that's what I do. See the 1st and 3rd top level bullets here on how to pull that off. FWIW, the .sync folder, in my experience, has always caused far more problems than it solves due to share wasted space. It's basically a solution for people who don't have a proper backup system setup, and Sync's archive functionality is literally the 1st thing I disable on every new Resilio deployment. I'm not saying Resilio should get rid of the feature, as it's good for some people.

@Andy+ Over the years of discussing things online I've found it's not particularly useful to question the basis of a decision a user makes for themselves. Whatever reasons @PacketMan has for switching, they work for him, and I think we should do him the courtesy of assuming he's thoroughly researched the topic and knows what's best for his use case.

PSA: 2.7.2 has been released; it fixes the issue.

Can confirm that 2.7.2 fixes the service installation bug from 2.7.1. Thanks and good job

@1VDJ I must admit I find your wording confusing, but in my years of using Sync since 2013 the best way get going is to start with an empty destination folder on the target machine. Probably not the answer you want to hear, but it's the path that's least likely to result in issues.

All my Windows installations are on Windows 10 Pro and Pro for Workstations.

Hmmm, works just fine for me. Make sure there are no other Resilio Sync processes running when you install as a service.

Just install the previous version (2.7.0) for now, it works just fine.

Running into the same problem Ah, so it is a bug in Resilio.

Hopefully soon; right now I can't install Sync to begin with on Windows 10 2004 due to it. UPDATE: The 2.7.0 installer doesn't have this problem. If you need to do a service installation, run that version for now and then wait for the 2.7.2 release to arrive.

Ha, I just realized the message Connection settings overridden by config actually means This state of this setting is not controlled or indicated in the web UI. Using "listen" : "0.0.0.0:8888" does in fact enable the web UI's accessibility to other machines on the LAN, it's just that the web UI won't indicate that to you. I'm now able to access Sync on the Ubuntu 20.04 machine from other machines on the LAN via Ubuntu20.04.IP.Address:8888. Problem solved! ----- UPDATE If you're running Resilio Sync under a particular username (such as your own) instead of under the default rslsync user, the relevant json file is found at: ~home/username/.config/resilio-sync/config.json

I'm running the latest Resilio Sync Home Pro on Ubuntu 20.04. I'd like to be able to access the Web UI from any machine on my network. Currently the setting to disable listening only to 127.0.0.1 is grayed out (see attached image) with the message Connection settings overridden by config, as shown below: To find out which config file was being used, I opened System Monitor, filtered the Processes tab for rslsync, and then looked at the Command Line column. There I found / usr/bin/rslsync --config /etc/resilio-sync/config.json Opening /etc/resilio-sync/config.json reads: { "storage_path" : "/var/lib/resilio-sync/", "pid_file" : "/var/run/resilio-sync/sync.pid", "webui" : { "listen" : "127.0.0.1:8888" } } Question: How do I enable the listening only setting in the UI via editing the config.json file? Changing "listen" : "127.0.0.1:8888" to "listen" : "0.0.0.0:8888" has no effect on the web UI after I restart the Resilio Sync service using # service resilio-sync restart If I use "listen" : "0.0.0.0" instead and then restart the service, the web UI is no longer accessible at all. Any ideas?

@papakpmartin FreeNAS most likely uses the FreeBSD repos upstream, and rslsync package is no longer available in those. You might be able to get it up and running manually using the binary available for direct download from the site. That's what I use on my FreeBSD 12.1 installation.

It's still priced at 501 USD ... unless you're a business or rich that's not cheap for an OS.

Fair enough. But you also have to accept what comes with that, too. Namely that enterprise products tend to beget enterprise prices by default unless you explicitly ask for an exception.

They do hold. The official list prices are what they are. The fact that you may have gotten a new BMW for the price of a used econobox doesn't change the fact that the BMW is a luxury car. When you take it in for service or try to buy aftermarket stuff for it, you're gonna pay just as much as someone who bought it at full price. Windows Server is an enterprise product with the usual enterprise trappings whether you paid $12 or nearly $7000 for it. Anyway, as staff already pointed out, all you have to do to resolve the issue is contact them directly. I had to do the same myself with TeamViewer because I'm on their free tier but I have so many client instances they thought I was a business. Took a couple weeks but all is good now. That's an easy solution anyone can manage.

Non-Windows OSes don't use SKUs per se, plus because pretty much everything that isn't Windows, AIX, or macOS is free my aforesaid assumption of being able to afford an enterprise license by virtue of already paying thousands of USD for an OS license doesn't apply for those other OSes. Personally, I run Sync Home Pro on Windows 10 Home & Pro, Android, Ubuntu, Debian, Raspbian, and FreeBSD without any issue. UPDATE: manually updated to 2.7.0 on my FreeBSD and Windows machines with no issue.

Grandfathering sounds like a workable solution in theory. Not sure if Resilio has that kind of license server-side granularity, but it would be a useful path forward.

What solution would you prefer? This is a common issue for just about all paid enterprise software: there's always some cutoff beyond which it's assumed you're running a business and can afford a business license. FTR, Windows Server pricing isn't inexpensive or free; so yes it is a reasonable assumption that anyone running WS can afford an enterprise level Sync license. And if you're not running a business, then you can get most of WS' non-domain functionality out of Pro, Pro for Workstations, or Enterprise. If you do need the domain functionality, then it is what it is. Neither Windows now Sync are free solutions; adjust your expectations accordingly.

AFAIK FreeBSD repos contain open source packages only, but I could be wrong. I actually do use FreeBSD, which is why I wrote the post 😛 Resilio Sync works perfectly for me, but then again I don't use the Selective Sync feature.

@PacketMan A couple things about that: There is no package available in the FreeBSD repos. To see for yourself, run pkg search rslsync on FreeBSD 12.1-RELEASE-p4. You'll get no results. The FreshPorts listing literally says there's no package available: You can't compile it yourself either because it's closed source so there's nothing to compile from Besides all of that, the most recent version in the FreeBSD repos is 2.6.3, which is a version behind the current stable release Now, there are some other FreeBSD-based distros such as GhostBSD that have rslsync in their repos, but I suspect that's because they also use the TrueOS repos, which are a superset of FreeBSD's. I would not suggest anyone use TrueOS' downstream repos on raw FreeBSD unless they want to run into package state/dependency problems.

@Mr Fethersmith Yw! @Andy+ @Mr Fethersmith My apologies for the broad brushed statement. I guess I just don't have a use case for any of those right now. I'm glad they work for you

Yw! Seafile is worse than Resilio Sync in every way IMO, but use what works best for you. Encrypted data is impossible to interpret without decryption. This means that all encrypted files must be decrypted before being read. With those 2 facts in mind, here's how full-disk encryption on computers works: The entire disk is encrypted, including the operating system (OS) At some point in the boot process, the bootloader (a small operating system that loads the requested OS into RAM and then hands off operation of the machine to it) realizes the disk the OS is on is encrypted, and requests the encryption key so it can start the OS The encryption key is provided in one of multiple ways depending on your config. We'll come back to this point later Now, this is the crucial part: the encryption key does not decrypt the entire disk at once. Rather, it decrypts data that is read from the disk in real-time and in memory so that the CPU can perform operations on it. All the data on the disk is still encrypted Similarly, all data the OS writes to disk is encrypted in memory before it's written to the disk. This includes data synced to Resilio folders on that disk. In other words, everything on the disk is always encrypted, regardless of machine state. Now, back to point 3. The key can be stored: internally on the computer itself, typically in a hardware component that we'll call an enclave for the sake of convenience externally. In this case, the key is provided by the user in the form of a password, biometrics, smart card, USB key, FIDO key, etc. Internal Pros: Convenient: machine can be restarted and booted up without the user being present. This is good for unattended updates and patching Cons: Because the encryption key is stored onboard, eventually at some point someone will discover an unpatchable vulnerability that can be used to extract it. You can avoid this by upgrading to a newer machine (security isn't inexpensive.) Enclave support in non-Windows OSes is hit or miss Windows and macOS have the best implementations of this. External Pros: Since the key is stored elsewhere, it's can be more difficult to crack than internal methods, especially if you use a FIDO 2FA token, for example Cons: Key has to be manually provided, which means OS can't automatically complete reboot and remote reboots are (mostly) impossible. OS can't effectively (kernel) patch itself There are ways around this but they're not inexpensive. Most OSes are on approximately equal footing here. It's gonna be easier on Windows and macOS but still possible otherwise. Now to something I forgot to talk about previously: the actual backup part of your strategy. You'll need to make backups of the synced files on the target devices, preferably to a separate disk. While that disk may be encrypted, it doesn't necessarily have to be, because Veeam Agent Free (Windows) and Restic (everything else) both allow encrypted backups. Another way Another way around this is to use Restic or Duplicati on one of (you only need one because they're all synced) your local machines + OpenVPN or Wireguard from the remote backup targets. Have the backup targets all connect to your LAN automatically via OpenVPN or Wireguard, then use Restic (which encrypts backups by default) or Duplicati (same) to push backups to the remote targets. Since the backups are encrypted with a locally stored key, you don't have to encrypt the targets, and your backups are both secure and unreadable by anyone without the password. This also eliminates the need for an extra disk at the target. You'll need to setup dynamic DNS on your local LAN so your remote targets always connect to the same URL. Set up unattended-upgrades on the remote Pis so they can keep themselves secure and updated. Much of this method is outside the scope of this forum as it doesn't involve Resilio Sync; I'd ask at r/OpenVPN, r/homelab, r/datahoarder, &/or r/raspberry_pi on Reddit if you have further questions. ______________________________________________________ I know this is a lot to absorb at once, so don't be disappointed or overwhelmed if you don't understand it right away. None of this is easy. If you want to use Raspberry Pis, the Another way method might be the easiest, since Pis weren't designed with device security in mind and I don't think they support disk encryption very well. If you want to the targets themselves to be disk-encrypted then you need recent x86-64 PCs.