rsync implications of ACL backups between different source & dest file systems

I'm having an issue using rsyncd (the daemon-ized version of rsync) to back up files from my macOS to my Synology server. Here's the command that fails:

% rsync -rlcAXtgoDiv --fake-super ~/scripts rsync://seamus@SynologyNAS-1/backups/scripts-backup/ > ~/scripts/log.txt 2>&1

This is the error: (in the logfile that I write and from command line):

rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(848) [sender=3.2.7]

After some experimentation, I think I've narrowed the source of the problem to the use of the -A option:

--acls, -A               preserve ACLs (implies --perms)
--xattrs, -X             preserve extended attributes
--fake-super             store/recover privileged attrs using xattrs

As I understand it, the --fake-super option allows rsync to store ACLs as extended attributes without requiring sudo... but I'm weak on the implications of all of the namespace business in man rsync. Further investigation led to the discovery that on the Synology server, this line was included in /etc/rsyncd.conf:

refuse options = acls

And so I edited /etc/rsyncd.conf, and commented the refuse options = acls line. When I re-ran the rsync command from earlier, it ran successfully :) But hang on - I do have a question: * The reported version of rsync on SynologyNAS-1 is:

rsync  version 3.1.2  protocol version 31

* In addition to the version difference (3.1.2 for Synology; 3.2.7 for macOS), the file system on Synology is btrfs - which is as opaque to me as APFS! My question is this: Am I actually backing up the correct (macos-compatible) ACLs that I hope - or have I simply silenced the guards? Any thoughts on this would be welcome. FWIW: I'd like to think I'm actually doing a correct backup ***because*** when I do the backup without rsyncd I don't see these errors. I wanted to switch to rsyncd to avoid the needless encryption step (this is all on my LAN) & hopefully streamline the backups.