Après une mise à jour de DSM sur un NAS Synology, une commande rsync qui fonctionnait parfaitement peut soudainement échouer avec une erreur Permission denied. Le réflexe naturel consiste alors à vérifier le mot de passe, la clé SSH, les droits du dossier ou les permissions DSM.

C’est utile, mais ce n’est pas toujours la vraie cause. Sur Synology, l’erreur peut aussi venir du chemin du binaire rsync côté NAS. Après certaines mises à jour DSM, le binaire peut changer d’emplacement, ou ne plus être trouvé correctement dans l’environnement SSH utilisé par rsync.

Dans ce cas, la solution consiste à indiquer explicitement à rsync où se trouve le binaire distant grâce à l’option --rsync-path.

Voici comment diagnostiquer et corriger proprement l’erreur rsync Permission denied sur un NAS Synology, sans bricoler les permissions au hasard ni sortir le grand classique chmod -R 777.

Le symptôme : rsync échoue après une mise à jour DSM

Vous lancez une commande rsync depuis un serveur Linux vers votre NAS Synology, par exemple pour sauvegarder un site, des fichiers ou un dossier système :

rsync -avz --delete \
	-e "ssh -p 22222" \
	/home/www/ \
	user@nas.example.local:/volume1/Backups/www/

Et vous obtenez une erreur du type :

Permission denied, please try again.
rsync: connection unexpectedly closed

Ou encore :

rsync error: unexplained error (code 255) at io.c

Si l’accès SSH fonctionne, que le compte est correct, et que les droits du dossier sont bons, le problème peut venir du chemin de rsync sur le NAS.

La solution : ajouter –rsync-path

La correction consiste à préciser le chemin complet du binaire rsync sur le NAS Synology avec l’option --rsync-path.

Depuis DSM 6, et encore avec DSM 7 dans la majorité des configurations, le chemin standard est :

/usr/bin/rsync

La commande devient donc :

rsync -avz --delete \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	/home/www/ \
	user@nas.example.local:/volume1/Backups/www/

Dans beaucoup de cas, cette option suffit à faire repartir une sauvegarde rsync qui échouait après une mise à jour DSM.

DSM 5, DSM 6 et DSM 7 : le chemin de rsync

Le point important de l’article d’origine est celui-ci : le chemin du binaire rsync a changé selon les versions de DSM.

Version DSM	Chemin courant de rsync	Option à tester
DSM 5	/usr/syno/bin/rsync	--rsync-path=/usr/syno/bin/rsync
DSM 6	/usr/bin/rsync	--rsync-path=/usr/bin/rsync
DSM 7	/usr/bin/rsync	--rsync-path=/usr/bin/rsync

Sous DSM 5, rsync pouvait se trouver dans /usr/syno/bin/rsync. À partir de DSM 6, Synology utilise généralement /usr/bin/rsync, un emplacement plus standard sous Linux.

Même si DSM 6 et DSM 7 trouvent souvent rsync sans aide, il reste pertinent d’ajouter --rsync-path=/usr/bin/rsync dans les scripts de sauvegarde. C’est explicite, stable, et cela évite les surprises lors d’une mise à jour.

Vérifier le chemin de rsync sur le NAS

Pour confirmer le bon chemin, connectez-vous au NAS en SSH :

ssh -p 22222 user@nas.example.local

Puis cherchez le binaire rsync :

which rsync
command -v rsync
ls -l /usr/bin/rsync
ls -l /usr/syno/bin/rsync

Si which rsync ne retourne rien, mais que /usr/bin/rsync existe, utilisez explicitement :

--rsync-path=/usr/bin/rsync

Si vous êtes sur un très vieux DSM et que le binaire existe dans /usr/syno/bin/rsync, utilisez plutôt :

--rsync-path=/usr/syno/bin/rsync

Exemple complet avec port SSH personnalisé

Si votre NAS Synology utilise un port SSH personnalisé, par exemple 22222, combinez --rsync-path avec -e "ssh -p 22222".

rsync -avz --delete \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	/home/www/ \
	user@nas.example.local:/volume1/Backups/www/

Pour un premier test, remplacez --delete par --dry-run, ou ajoutez --dry-run à la commande :

rsync -avz --dry-run \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	/home/www/ \
	user@nas.example.local:/volume1/Backups/www/

Cela permet de vérifier la connexion, les chemins et les droits sans modifier les fichiers côté NAS.

Attention à la différence entre rsync via SSH et rsync daemon

Le correctif --rsync-path concerne surtout rsync via SSH. C’est le mode utilisé quand votre destination contient un seul deux-points après le nom du serveur.

Mode	Syntaxe	Transport	Exemple
rsync via SSH	nas:/chemin/distant/	SSH	user@nas:/volume1/Backups/
rsync daemon	nas::module/	Service rsync	user@nas::NetBackup/

Exemple via SSH :

rsync -avz ./documents/ user@nas:/volume1/Backups/documents/

Exemple via daemon rsync :

rsync -avz ./documents/ user@nas::NetBackup/documents/

Le détail qui change tout : un seul deux-points utilise SSH. Deux deux-points utilisent le daemon rsync. Les permissions, les comptes et les chemins ne se diagnostiquent pas de la même façon.

Vérifier que SSH fonctionne

Avant d’accuser rsync, vérifiez que SSH fonctionne avec le même utilisateur et le même port.

ssh -p 22222 user@nas.example.local

Si SSH échoue, corrigez d’abord SSH : utilisateur, mot de passe, clé, port, pare-feu ou droits DSM. Inutile de tester rsync tant que le transport échoue.

Pour diagnostiquer plus finement :

ssh -vvv -p 22222 user@nas.example.local

Les lignes Permission denied, Offering public key et Authentication failed indiquent généralement si le problème vient de l’authentification, de la clé SSH ou du compte DSM.

Vérifier que le service SSH est activé dans DSM

Dans DSM, vérifiez que SSH est activé :

Panneau de configuration → Terminal & SNMP → Terminal → Activer le service SSH

Vérifiez aussi le port utilisé. Si vous avez changé le port SSH dans DSM, vous devez le préciser dans la commande rsync avec -e "ssh -p PORT".

rsync -avz \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Vérifier le service rsync dans DSM

Si vous utilisez le mode daemon rsync, vérifiez que le service rsync est activé dans DSM :

Panneau de configuration → Services de fichiers → rsync

Activez le service rsync, puis vérifiez les privilèges des utilisateurs autorisés. Synology documente cette configuration dans son aide DSM, notamment l’activation du service et la gestion des comptes autorisés.

Pour lister les modules rsync disponibles :

rsync nas.example.local::

Avec un utilisateur :

rsync user@nas.example.local::

Si aucun module n’apparaît, vérifiez le service rsync, les comptes rsync et les privilèges dans DSM.

Tester les ports SSH et rsync

Depuis la machine cliente, testez d’abord le port utilisé.

Pour SSH :

nc -vz nas.example.local 22

Pour SSH avec un port personnalisé :

nc -vz nas.example.local 22222

Pour rsync daemon :

nc -vz nas.example.local 873

Si le port ne répond pas, le problème n’est pas encore une permission de fichier. Vérifiez le service DSM, le pare-feu Synology, le pare-feu de votre réseau, le VLAN, le VPN ou l’adresse IP du NAS.

Vérifier les droits du dossier partagé dans DSM

Si --rsync-path ne suffit pas, revenez au diagnostic classique des droits. Dans DSM, ouvrez :

Panneau de configuration → Dossier partagé

Sélectionnez le dossier de destination, puis vérifiez les permissions.

• L’utilisateur rsync a-t-il le droit de lecture/écriture ?
• Le groupe de l’utilisateur a-t-il une règle contradictoire ?
• Une règle “Aucun accès” bloque-t-elle l’utilisateur ?
• Les permissions héritées sont-elles cohérentes ?
• Les ACL avancées DSM sont-elles activées ?

Dans DSM, une interdiction explicite peut prendre le dessus sur une autorisation ailleurs. Si l’utilisateur appartient à plusieurs groupes, vérifiez donc tous les groupes concernés.

Tester l’écriture avec le même utilisateur

Connectez-vous au NAS avec le même utilisateur que celui utilisé par rsync, puis testez une écriture dans le dossier de destination.

ssh -p 22222 user@nas.example.local
touch /volume1/Backups/test-rsync.txt
rm /volume1/Backups/test-rsync.txt

Si touch renvoie Permission denied, rsync n’est pas le problème principal. L’utilisateur n’a pas le droit d’écrire à cet endroit.

Dans ce cas, corrigez les permissions DSM du dossier partagé plutôt que de bricoler la commande rsync.

Vérifier le chemin de destination

Sur Synology, les dossiers partagés se trouvent généralement sous :

/volume1/nom-du-dossier-partage/

ou, selon la configuration :

/volume2/nom-du-dossier-partage/

Une erreur fréquente consiste à viser un chemin qui n’existe pas, ou à confondre le nom du module rsync avec le chemin réel du système de fichiers.

Testez côté NAS :

ls -ld /volume1/Backups
ls -la /volume1/Backups

Si le dossier n’existe pas, créez-le depuis DSM ou en ligne de commande avec un utilisateur autorisé.

Attention à rsync -a sur Synology

L’option -a, ou --archive, est très pratique. Elle active plusieurs options : récursif, conservation des liens symboliques, permissions, timestamps, groupes, propriétaires et fichiers spéciaux selon le contexte.

Sur un NAS Synology, -a peut provoquer des erreurs si l’utilisateur distant n’a pas le droit de préserver certains propriétaires, groupes ou permissions.

Exemple d’erreur typique :

rsync: failed to set permissions on "/volume1/Backups/fichier": Operation not permitted (1)

Dans ce cas, testez une commande moins agressive :

rsync -rtvz \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Ici, on conserve la récursivité et les dates, mais on évite de forcer propriétaire, groupe et permissions. C’est souvent suffisant pour une sauvegarde de fichiers personnels, de médias ou de dossiers web.

Éviter les problèmes de propriétaire et de groupe

Si vous voyez des erreurs liées à chown, chgrp ou aux groupes, évitez de préserver propriétaire et groupe.

À éviter si vous n’êtes pas root côté destination :

rsync -a ./source/ user@nas:/volume1/Backups/

Préférez :

rsync -rtv --no-owner --no-group \
	--rsync-path=/usr/bin/rsync \
	./source/ user@nas:/volume1/Backups/

Si vous utilisez tout de même -a, ajoutez explicitement :

rsync -a --no-owner --no-group \
	--rsync-path=/usr/bin/rsync \
	./source/ user@nas:/volume1/Backups/

Cela évite à rsync de tenter de reproduire des propriétaires ou groupes qui n’existent pas sur le NAS, ou que l’utilisateur distant n’a pas le droit de définir.

Forcer des permissions propres à l’arrivée

Si vous voulez définir des permissions raisonnables sur les fichiers transférés, utilisez --chmod. Cette option applique des modes de permissions aux fichiers transférés. Elle est utile quand les permissions sources ne correspondent pas à ce que vous voulez sur la destination.

rsync -rtvz \
	--rsync-path=/usr/bin/rsync \
	--chmod=D755,F644 \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Ici :

• D755 applique 755 aux dossiers ;
• F644 applique 644 aux fichiers.

Pour un dossier partagé collaboratif, vous pouvez préférer des permissions de groupe plus ouvertes :

rsync -rtvz \
	--rsync-path=/usr/bin/rsync \
	--chmod=D775,F664 \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Mais sur Synology, les ACL DSM peuvent prendre le dessus ou cohabiter avec les permissions POSIX. Ne mélangez pas tout sans tester.

Cas des ACL Synology

DSM utilise des permissions de dossiers partagés et peut aussi gérer des ACL avancées. Ces ACL peuvent produire des comportements étranges si vous raisonnez uniquement en permissions Linux classiques.

Exemple : ls -l peut sembler correct, mais DSM refuse tout de même l’écriture à cause d’une règle d’ACL ou d’un héritage de permissions.

Dans DSM, vérifiez donc les permissions depuis l’interface, pas seulement avec chmod et ls -l.

Dans beaucoup de cas, la correction propre consiste à modifier les droits du dossier partagé via DSM, puis à appliquer les permissions aux sous-dossiers si nécessaire. C’est plus sûr que de lancer un chmod -R depuis SSH et de casser les ACL attendues par DSM.

Commande de diagnostic recommandée

Pour diagnostiquer sans rien modifier, utilisez --dry-run et augmentez la verbosité.

rsync -avvn --delete \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Options utiles :

• -n ou --dry-run : simulation ;
• -vv : plus de détails ;
• --itemize-changes : affiche les changements prévus ;
• --stats : affiche un résumé du transfert.

Exemple complet :

rsync -avvn --itemize-changes --stats \
	--rsync-path=/usr/bin/rsync \
	-e "ssh -p 22222" \
	./source/ user@nas.example.local:/volume1/Backups/source/

Quand la simulation est propre, retirez -n pour lancer le vrai transfert.

Automatiser avec cron

Une fois la commande validée, vous pouvez l’automatiser avec cron.

crontab -e

Exemple tous les jours à 2h30 :

30 2 * * * rsync -avz --delete --rsync-path=/usr/bin/rsync -e "ssh -p 22222" /home/www/ user@nas.example.local:/volume1/Backups/www/ >> /home/matt/rsync-synology.log 2>&1

Si vous utilisez une clé SSH, vérifiez que cron utilise le bon utilisateur, la bonne clé et le bon fichier known_hosts. Beaucoup de commandes fonctionnent en shell interactif puis échouent en cron. Cron est très littéral. Un peu trop premier degré, même pour un démon.

Lire les logs côté Synology

Pour les erreurs persistantes, consultez les journaux DSM.

Dans DSM :

Centre des journaux

Regardez les événements liés à l’utilisateur, à SSH, au service rsync ou aux accès fichiers.

En SSH, vous pouvez aussi inspecter certains logs selon votre modèle et votre version DSM. Les chemins peuvent varier, donc privilégiez d’abord le Centre des journaux DSM.

Exemples d’erreurs et corrections

Erreur	Cause probable	Correction
Permission denied après update DSM	rsync distant introuvable ou mauvais chemin	Ajouter --rsync-path=/usr/bin/rsync
Permission denied, please try again	Authentification SSH échouée	Vérifier utilisateur, mot de passe, clé SSH et accès SSH DSM
failed to set permissions	-a tente de préserver des permissions non autorisées	Utiliser -rtv, --no-owner, --no-group ou --chmod
Permission denied (13)	Droits insuffisants sur le dossier destination	Corriger les permissions DSM du dossier partagé
Connection refused	Service SSH ou rsync non actif, ou mauvais port	Activer le service et vérifier le port
Unknown module	Module rsync inexistant ou mauvais nom	Lister les modules avec rsync nas::
Read-only file system	Volume monté en lecture seule ou problème disque	Vérifier l’état du volume dans DSM

Ce qu’il ne faut pas faire

• Ne lancez pas chmod -R 777 sur un dossier partagé Synology.
• Ne désactivez pas toutes les ACL DSM pour “tester vite fait”.
• Ne donnez pas les droits admin au compte rsync sans raison.
• Ne confondez pas chemin SSH et module rsync daemon.
• Ne gardez pas --delete sans tester avec --dry-run.
• Ne préservez pas propriétaires et groupes si l’utilisateur distant n’a pas le droit de les définir.
• Ne supprimez pas --rsync-path d’un script stable sans tester après une mise à jour DSM.
• Ne testez pas uniquement depuis votre poste si la tâche finale tourne depuis un serveur ou un cron.

Checklist de diagnostic

• Identifier le mode utilisé : SSH ou daemon rsync.
• Si vous utilisez SSH, tester avec --rsync-path=/usr/bin/rsync.
• Vérifier le chemin de rsync côté NAS avec which rsync.
• Tester SSH avec le même utilisateur que rsync.
• Vérifier que SSH est activé dans DSM.
• Tester le port avec nc.
• Vérifier le service rsync DSM si vous utilisez nas::module.
• Lister les modules si vous utilisez le mode daemon.
• Vérifier les droits du dossier partagé dans DSM.
• Tester l’écriture avec touch côté NAS.
• Vérifier le chemin réel sous /volume1 ou /volume2.
• Remplacer -a par -rtv si les permissions posent problème.
• Ajouter --dry-run avant toute synchronisation destructive.
• Consulter le Centre des journaux DSM.

À lire également

Si vous utilisez rsync pour sauvegarder vos serveurs ou administrer un NAS Synology, ces guides complètent utilement celui-ci :

• Utiliser Rsync pour sauvegarder un serveur Linux vers un NAS Synology
• Transférer des fichiers d’un serveur à un autre avec rsync sous Linux
• NAS Synology : retrouver l’accès SSH pour rsync après une mise à jour DSM
• Se connecter depuis un serveur vers un NAS Synology avec des clés SSH, sans mot de passe
• Mapper un répertoire du NAS sous Ubuntu

À retenir

• Après une mise à jour DSM, rsync Permission denied peut venir du chemin du binaire rsync côté NAS.
• La correction historique de cet article est --rsync-path=/usr/bin/rsync.
• Sous DSM 5, le chemin pouvait être /usr/syno/bin/rsync.
• Sous DSM 6 et DSM 7, le chemin courant est généralement /usr/bin/rsync.
• Le correctif --rsync-path concerne surtout rsync via SSH.
• Un seul deux-points utilise SSH ; deux deux-points utilisent le daemon rsync.
• Si --rsync-path ne suffit pas, vérifiez SSH, le port, les droits DSM, les ACL et le chemin de destination.
• Testez toujours avec --dry-run avant une synchronisation avec --delete.

En résumé, si rsync échoue avec Permission denied après une mise à jour DSM, commencez par tester --rsync-path=/usr/bin/rsync. C’est souvent la correction la plus rapide sur Synology. Ensuite seulement, passez au diagnostic classique : accès SSH, port, compte DSM, droits du dossier partagé, ACL et options rsync. La bonne solution n’est pas de forcer les permissions au hasard, mais de pointer vers le bon binaire et de donner les bons droits au bon utilisateur.

Sources

• Synology DSM — rsync
• Synology Knowledge Center — rsync
• Linux man-pages — rsync(1)
• SkyMinds — NAS Synology : retrouver l’accès SSH pour rsync après une mise à jour DSM

Report a typo