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>
38 lines
1.9 KiB
Markdown
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).
|