runbook: scp/sftp indisponibles sur ce Synology, contournement cat|ssh

Promu en runbook common/ transverse -- rencontre 2 fois en contextes
differents (transfert git bundle, deploiement fichier partage 3 instances),
n'avait jusque-la qu'une note de session etroite (nas-deploy-ops, scopee au
seul cas du git bundle nas-runbooks).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

common/synology-scp-sftp-indisponible-cat-ssh.md

@@ -0,0 +1,37 @@
+# Synology NAS : scp/sftp indisponibles pour transférer un fichier depuis le Mac
+
+**Symptôme** : `scp -P 22222 fichier Best0f@192.168.100.33:/volume1/docker/...` échoue avec
+`scp: dest open "...": No such file or directory`, alors que le chemin de destination existe
+bel et bien et que `ssh` vers le même hôte fonctionne normalement.
+
+**Cause** : le sous-système SFTP n'est pas activé (ou pas correctement exposé) sur ce DSM pour
+l'utilisateur/la clé utilisés en automatisation. `scp` moderne (protocole SFTP par défaut) et
+`sftp` échouent tous les deux de la même façon. `ssh` lui-même n'est pas affecté — seul le
+sous-canal de transfert de fichiers l'est.
+
+**Contournement** : piper le contenu via une session `ssh` classique plutôt que d'ouvrir un
+canal SFTP :
+
+```
+cat fichier_local | ssh nas 'cat > /volume1/docker/chemin/destination'
+```
+
+Fonctionne pour tout fichier texte/binaire raisonnable (déjà utilisé pour des scripts Python,
+des `.md`, un `git bundle`). Pour un dossier entier, `tar` avant/après :
+
+```
+tar czf - dossier_local | ssh nas 'cd /volume1/docker/chemin && tar xzf -'
+```
+
+**Portée** : ce n'est pas propre à un projet — touche tout transfert de fichier vers le
+filesystem de l'hôte NAS, quel que soit l'instance/la sphère à l'origine du besoin. Déjà
+rencontré deux fois dans des contextes différents (transfert d'un `git bundle` pour
+`nas-runbooks`, déploiement d'un fichier de mémoire partagée vers les 3 instances Hermes) —
+d'où sa promotion en runbook `common/` plutôt que de rester une note de session isolée.
+
+**Ce qui marche normalement** : `ssh`, `git` (via HTTP avec token, pas SSH), `rsync` non
+testé sur cette voie (probablement affecté par la même cause si basé sur SFTP, à vérifier avant
+de s'y fier).
+
+Voir aussi `nas-deploy-ops` (mémoire Claude Code, référence) pour les autres pièges d'accès NAS
+(port SSH 22222, chemins, git absent de l'hôte).