christian/recurring-checklist
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fetch with ssh cat: this NAS has no SFTP subsystem

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Waters Church
2026-10-08 09:37:58 -04:00
co-authored by Claude Opus 5
parent cf3c496c17
commit f52c3c17ba
1 changed files with 7 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backup-to-drive.sh
+7 -2
View File
@@ -61,7 +61,7 @@ done
# which is how a ~275 KB JSON arrived truncated often enough to email a false alarm most # 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 # 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 # 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 # 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. # password here any more, and nothing to read out of the keychain.
@@ -132,7 +132,12 @@ else
ok=0 ok=0
for try in 1 2 3; do for try in 1 2 3; do
: > "$TMP" : > "$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 # 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 # 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. # than one that is obviously missing — it just verifies rather than repairs now.