rsync over SSH against a Synology NAS fails instantly with a permission error. Your credentials are fine. This is DSM hardening working as intended, not a bug. Stop fighting rsync's flags and use tar instead.
Run rsync from a remote machine over SSH against the NAS. It fails immediately.
Permission denied, please try again.
Then the connection closes.
Your SSH credentials are correct. The same account can SSH in and run other commands fine.
Check the binary on the NAS with command ls -la /usr/bin/rsync
ls -la /usr/bin/rsync
-rwsr-xr-x 1 root root ... /usr/bin/rsync
That s in the permission bits means DSM's rsync is setuid-root.
It always runs as root no matter who calls it. DSM's own backup features rely on that.
So DSM blocks a setuid-root binary from being called non-interactively over SSH.
This is not a misconfiguration to fix. A setuid-root binary any remote SSH command can invoke is exactly what you want restricted.
You need working sudo on the NAS for that account.
Stream the data across with tar piped over SSH.
ssh <synology> "sudo -n tar -C /volume1/docker/<app> -cf - --exclude=cache --exclude=tmp ." \
| tar -C <local-staging> -xf -
Then push it on to where it actually needs to land.
tar -C <local-staging> -cf - . | ssh <destination-host> "tar -C /path/to/target -xf -"
Check whether the service already goes through DSM's own reverse proxy.
If it does, the cutover after the data moves is one change. Point that proxy rule's backend at the new location. No DNS change. No new TLS certificate. Nothing else to touch.
Do not assume a Synology migration needs a DNS and cert migration on top of the data move. Often it does not.