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