Servers and infrastructure on errno

Synology NAS: scp fails with "subsystem request failed on channel 0"

Sat, 22 Aug 2026 00:00:00 +0000

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.

docker manifest inspect fails with "permission denied" on /etc/docker/certs.d

Wed, 12 Aug 2026 00:00:00 +0000

Symptom

A deployment script verifies that the requested tag exists before it touches a running stack. Under the deploy user it fails:

$ docker manifest inspect registry.example.com/backend:1.42
error: open /etc/docker/certs.d/registry.example.com/ca.crt: permission denied

Under root on the same node the identical command returns the manifest. Pulling images works for the deploy user too, which makes the failure look arbitrary.

Why root works and your user does not

docker manifest inspect is one of the CLI commands that talks to the registry from the client process, not through the daemon. So it needs to read the registry CA itself — and /etc/docker/certs.d/... is intentionally readable only by root and the daemon.

Editing a Subversion repository without a working copy: svnmucc

Wed, 12 Aug 2026 00:00:00 +0000

The problem with a checkout

Release repositories tend to be large and deeply nested. Changing one deploy script means a checkout of a tree you do not care about, a build-up of stale working copies on a jump host, and a real risk of committing something you did not intend because the working copy had other local modifications.

For scripted or one-off edits, skip the working copy entirely.

svnmucc: multiple URL commands, one commit

svnmucc \
 put local/stack-deploy-or-update.sh \
 svn://svn.example.com/svn/release/trunk/projects/app/test/docker/stack-deploy-or-update.sh \
 rm svn://svn.example.com/svn/release/trunk/projects/app/test/docker/portainer-compose.yml \
 -m "APP: unify deploy script, drop portainer compose" \
 --username builder --non-interactive --no-auth-cache

Everything on that command line lands as one atomic revision — which is the property you want when a change spans several files and half of it applied would leave the environment broken. The available operations are put, rm, mkdir, cp, mv and propset, all addressed by URL.