From f52c3c17baed67413600dbebbe43e0a86b0bd303 Mon Sep 17 00:00:00 2001 From: Waters Church Date: Thu, 8 Oct 2026 09:37:58 -0400 Subject: [PATCH] Fetch with ssh cat: this NAS has no SFTP subsystem MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous commit moved the fetch to scp, which was a regression: modern scp speaks SFTP, this Synology does not enable that subsystem, and every file failed with "subsystem request failed on channel 0". It failed safe — nothing was copied and nothing was emailed — but nothing would have copied again either. Caught by running it rather than by reading it. With key auth there is no pty in the way, so streaming the file through a plain ssh session is byte-exact. Verified against the NAS's own byte count: 390163 in, 390163 out, parses with 43 lists. scp -O would also work, but the legacy protocol is being retired from OpenSSH. Worth recording what this proves about the original fault: today's file was never corrupt. cat was never the problem. The pty expect wrapped around it was. Co-Authored-By: Claude Opus 5 --- backup-to-drive.sh | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/backup-to-drive.sh b/backup-to-drive.sh index aa86e6a..abae2c7 100755 --- a/backup-to-drive.sh +++ b/backup-to-drive.sh @@ -61,7 +61,7 @@ done # which is how a ~275 KB JSON arrived truncated often enough to email a false alarm most # nights between 29 September and 8 October 2026. A pty does line discipline and has finite # buffers; it is not a file transfer. With a key there is no password prompt to automate, so -# the file can come over scp and be byte-exact. +# the file can be streamed over a plain ssh session and be byte-exact. # # The key lives on this machine only and is authorised on the NAS for this user. There is no # password here any more, and nothing to read out of the keychain. @@ -132,7 +132,12 @@ else ok=0 for try in 1 2 3; do : > "$TMP" - scp -q $SSH_OPTS "$NAS_USER@$NAS_HOST:$REMOTE_DIR/$f" "$TMP" 2>/dev/null || true + # `ssh cat`, not scp: this NAS has no SFTP subsystem, and modern scp speaks SFTP, so + # scp fails on every file with "subsystem request failed on channel 0". `scp -O` would + # work too but the legacy protocol is on its way out of OpenSSH. With key auth there + # is no pty in the way, so cat is byte-exact — verified against the NAS's own byte + # count. It was only ever the pty that corrupted this, never cat. + ssh $SSH_OPTS "$NAS_USER@$NAS_HOST" "cat $REMOTE_DIR/$f" > "$TMP" 2>/dev/null || true # scp delivers the file byte for byte, so there is nothing to slice out of a transcript # any more. The check stays because a backup that is present but unreadable is worse # than one that is obviously missing — it just verifies rather than repairs now.