Synology NAS: scp fails with "subsystem request failed on channel 0"
Symptom
SSH into the NAS works. Copying a file off it does not:
$ ssh [email protected] 'echo login ok'
login ok
$ scp [email protected]:/volume1/media/clip.mp4 .
subsystem request failed on channel 0
scp: Connection closed
sftp fails the same way:
$ sftp [email protected]
Connection closed.
subsystem request failed on channel 0
Diagnosis
Modern scp no longer uses the legacy remote-copy protocol; it speaks SFTP, which requires the server
to offer an sftp subsystem. On this DSM installation, that subsystem is not exposed, so the channel
request is rejected before any transfer starts. The interactive shell is unaffected, which is exactly why
the failure looks so confusing: authentication, host key and network are all fine.
The error text is the server refusing a subsystem, not a permission or path problem — a wrong path would
give you No such file or directory after a successful subsystem handshake.
Fix: move bytes over a plain SSH channel
Skip SFTP entirely and stream through the shell you already have.
Download from the NAS:
sshpass -e ssh [email protected] 'cat "/volume1/media/clip.mp4"' > clip.mp4
Upload to the NAS:
cat clip.mp4 | ssh [email protected] 'cat > "/volume1/media/clip.mp4"'
Notes that matter in practice:
- Quote the remote path inside the remote command; spaces in
/volume1/...share names are common. - Redirect binary output straight to a file. Do not let it touch a terminal or a pipeline that rewrites newlines.
- For a directory, tar on the fly:
ssh [email protected] 'tar cf - -C /volume1/media .' | tar xf - scp -O(force legacy protocol) is worth one attempt, but it also fails when the DSM build lacks the legacy remote-copy path.
Related trap: the bundled ffmpeg
If your reason for copying media around is transcoding on the NAS, stop there. The ffmpeg binary shipped
with DSM is stripped: in my case it could neither decode AAC nor encode at all, so an “obvious” plan of
doing the conversion where the files live simply does not work. Copy the file to a workstation, convert it
there, copy it back with the cat pattern above.
Verify
$ ssh [email protected] 'md5sum "/volume1/media/clip.mp4"'
d41d8cd98f00b204e9800998ecf8427e /volume1/media/clip.mp4
$ md5sum clip.mp4
d41d8cd98f00b204e9800998ecf8427e clip.mp4
Matching checksums are the point: a broken redirect corrupts silently, so always compare after a
cat-based transfer.