Synology / Migrations

Why rsync Over SSH Fails Against a Synology NAS With "Permission Denied"

Migrating data off a Synology NAS by SSHing in and running rsync is the obvious approach — right up until it fails instantly with a permission error and a closed connection, for no reason the command itself explains. This is deliberate DSM security hardening, not a bug, and the real workaround is simpler than fighting rsync's flags.

The symptom

Running rsync from a remote machine straight over SSH against a Synology NAS fails immediately:

Permission denied, please try again.

followed by the connection closing — even with correct SSH credentials, and even if the same account can SSH in and run other commands fine.

Why it happens

Check the binary itself on the NAS:

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 regardless of who invokes it, a real design choice for how DSM's own backup features use it. DSM specifically blocks a setuid-root binary like this from being invoked non-interactively over SSH. That's genuine security hardening working as intended, not a misconfiguration to fix — a setuid-root binary being freely invokable by any remote SSH command is exactly the kind of thing worth restricting.

The workaround: skip rsync, stream a tar instead

If you already have working sudo access on the NAS for the account in question, the cleanest path is streaming the data across with tar piped directly over SSH rather than fighting rsync's restriction:

ssh <synology> "sudo -n tar -C /volume1/docker/<app> -cf - --exclude=cache --exclude=tmp ." \
  | tar -C <local-staging> -xf -

Then push it on to wherever it actually needs to land:

tar -C <local-staging> -cf - . | ssh <destination-host> "tar -C /path/to/target -xf -"

Why two hops instead of one direct stream: piping data directly between two remote hosts from a third machine isn't something SSH/tar naturally supports in that direction — staging locally first (even briefly) and then pushing on to the real destination is the reliable pattern, not a workaround for a limitation specific to this NAS.

Worth checking before assuming a bigger migration is needed

If the service being migrated is already reverse-proxied through DSM's own built-in reverse proxy (rather than exposed directly), the actual cutover once data has moved can be as small as changing that one proxy rule's backend address to point at the new location — no DNS change, no new TLS certificate, nothing else to touch. Check whether the domain already routes through DSM's reverse proxy before assuming a Synology migration needs a parallel DNS/cert migration on top of the data move — often it doesn't.