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 nasuser@nas.example.lan 'echo login ok'
login ok
$ scp nasuser@nas.example.lan:/volume1/media/clip.mp4 .
subsystem request failed on channel 0
scp: Connection closed
sftp fails the same way:
$ sftp nasuser@nas.example.lan
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 nasuser@nas.example.lan 'cat "/volume1/media/clip.mp4"' > clip.mp4
Upload to the NAS:
cat clip.mp4 | ssh nasuser@nas.example.lan '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 nasuser@nas.example.lan '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 nasuser@nas.example.lan '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.