Files
nas-runbooks/common/synology-scp-sftp-indisponible-cat-ssh.md
AntigravityandClaude Sonnet 5 900ce68e72 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>
2026-08-17 00:25:56 +01:00

38 lines
1.9 KiB
Markdown

# 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).