Le premier soucis est que le password soit demandé. Normalement, un couple de clés privée et public a été généré et la clé public a été déployée sur le nas pour que le password ne soit plus demandé.
Il faut probablement refaire le point 1 à 7 de la « préparation des clé ssh » dans la procédure ci-dessus.
Le but est de pouvoir faire un ssh jeedompi@192.168.0.9 depuis le compte root du jeedom sans qu’un password ne soit demandé. Nous pourrons ensuite allez plus loin dans la config.
J’ai repris les points 1 à 7 comme suivant
jeedompi@FreePiJDom:~$ sudo su
root@FreePiJDom:/home/jeedompi#cd
root@FreePiJDom:~#ls .ssh
id_rsa id_rsa.pub known_hosts
root@FreePiJDom:~#ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:U7OAYO+aKSWlaAbbiijLBmWallq9ZbO45i6EHf53EVI root@FreePiJDom
The key's randomart image is:
+---[RSA 2048]----+
| o |
| . o .E |
|. . o.. o |
|.++o .. .o o |
|o@=o. ..S.. |
|X+=o.++ .. |
|Oo..+= o . |
|+o..= o . |
|o. =+o . |
+----[SHA256]-----+
root@FreePiJDom:~# ssh-copy-id -i .ssh/id_rsa.pub jeedompi@192.168.0.9
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: « .ssh/id_rsa.pub »
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys
jeedompi@192.168.0.9's password:JE RENTRE MON MDP et enter
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'jeedompi@192.168.0.9'"
and check to make sure that only the key(s) you wanted were added.
root@FreePiJDom:~#exit
jeedompi@FreePiJDom:~$
jeedompi@FreePiJDom:~$ sudo su
root@FreePiJDom:/home/jeedompi#cd
root@FreePiJDom:~#ssh jeedompi@192.168.0.9
j'obtiens :
[jeedompi@NASF62441 ~]$
[jeedompi@NASF62441 ~]$ ls -la /DataVol1
/bin/ls: cannot access /DataVol1: No such file or directory
[jeedompi@NASF62441 ~]$ ls -la /DataVol1/qnap_rsync
/bin/ls: cannot access /DataVol1/qnap_rsync: No such file or directory
[jeedompi@NASF62441 ~]$ pwd
/share/homes/jeedompi
Si je procède part : (j’obtiens)
jeedompi@FreePiJDom:~ $ sudo su
root@FreePiJDom:/home/jeedompi# ssh jeedompi@192.168.0.9
[jeedompi@NASF62441 ~]$ ls -la /DataVol1
/bin/ls: cannot access /DataVol1: No such file or directory
[jeedompi@NASF62441 ~]$ ls -la /DataVol1/qnap_rsync
/bin/ls: cannot access /DataVol1/qnap_rsync: No such file or directory
[jeedompi@NASF62441 ~]$ pwd
/share/homes/jeedompi
sous l’user : il me demande le mot de passe
jeedompi@FreePiJDom:~ $ ssh jeedompi@192.168.0.9
jeedompi@192.168.0.9's password:
J’ai essayé de te détailler au mieux la façon dont je suis ton tuto.
Ceci montre que les clés ssh sont bien déployées. Il a été possible de se connecter sur le 192.168.0.9, compte jeedompi depuis le compte root de FreePiJDom sans avoir besoin de saisir le password. 
Maintenant, il faut un répertoire existant pour accueillir les copies de backup. Je propose de simplement créer un répertoire dans le HOMEDIR de jeedompi sur 192.168.0.9
Depuis le compte rootsur FreeOiJDom, faire un ssh jeedompi@192.168.0.9
Ensuite, lancer le commande mkdir backup_jeedom
[jeedompi@NASF62441 ~]$ mkdir backup_jeedom
[jeedompi@NASF62441 ~]$ exit
On peut enfin configurer les sauvegardes jeedom
[Backup] IP : 192.168.0.9
[Backup] Utilisateur : jeedompi
[Backup] Chemin: /share/homes/jeedompi/backup_jeedom
Un test devrait être concluant 
Le test à été concluant.
Du coup j’ai lancé une sauvegarde pour aller jusqu’au bout 
retour d’erreur :
Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom/ 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory
Information de la sauvegarde :
[START BACKUP]
***************Start of Jeedom backup at 2021-03-30 09:29:50***************
Envoi l'évènement de début de sauvegarde...OK
Vérification des droits sur les fichiers...
OK
Vérification de la base de données...OK
Sauvegarde la base de données...OK
Persistance du cache :
OK
Création de l'archive...
tar: .: file changed as we read it
OK
Nettoyage de l'ancienne sauvegarde...OK
Send backup Ssh...
Delete backup too old :
{"filename":"backup-FreePiJDom-4.1.20-2021-03-30-09h29.tar.gz","size":"151879090","datetime":"2021-03-30 09:34:00"}
Delete backup too old :
{"filename":null,"size":null,"datetime":"2021-03-30 09:32:31"}[2021-03-30 09:32:32][ERROR] : Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom// 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory
/!\ Erreur sur sudo ssh jeedompi@192.168.0.9 rm /share/homes/jeedompi/backups_jeedom// 2>&1 valeur retournée : 1. Détails : rm: '/share/homes/jeedompi/backups_jeedom' is a directory /!\OK
Limitation de la taille des sauvegardes à 500 Mo...
OK
Nom de la sauvegarde : /var/www/html/core/php/../../backup/backup-FreePiJDom-4.1.20-2021-03-30-09h29.tar.gz
Vérification des droits sur les fichiers...
OK
Envoi l'évènement de fin de sauvegarde...OK
Durée de la sauvegarde : 164s
***************Fin de la sauvegarde de Jeedom***************
[END BACKUP SUCCESS]
Bonjour,
Je suis en Jeedom 4.1.20.
Depuis quelques temps, j’avais également des erreurs timeout et mon backup sur nas (Syno) ne faisait que 50 à 100Mo alors que le complet fait environ 230Mo.
Après avoir modifié le fichier /core/repo/samba.repo.php ligne 134 pour forcer le timeout à 120s :
public static function makeSambaCommand($_cmd, $_type = 'backup') {
return system::getCmdSudo() . 'smbclient -t 120 ' . config::byKey('samba::' . $_type . '::share') . ' -U "' . config::byKey('samba::' . $_type . '::username') . '%' . config::byKey('samba::' . $_type . '::password') . '" -I ' . config::byKey('samba::' . $_type . '::ip') . ' -c "' . $_cmd . '"';
}
et avoir redémarré… Les backup semblent maintenant passer l’etape de copie pour moi… Reste à vérifier sur le long terme.
Ce que je ne comprend pas c’est qu’en reprenant la ligne de commande de copie en echec dans le log et en l’exécutant en ssh cela passait toujours sans problème…
Bon courage.
Si le timeout de 120 résoud ton problème ( il semble que ce ne soit pas le cas pour @iznogood ) je te suggère d’utiliser la méthode de @oozean:
Le paramètre -t 120 dans la configuration résistera bien mieux à une mise à jour que si tu modifies le code qui sera écrasé lorsque tu passeras à une version supérieur du core.
Je ne comprend pas d’où vient l’erreur. J’ai l’impression que c’est parce que le répertoire est encore vide mais je n’ai pas réussi à le reproduire chez moi.
J’ai un NAS Synology DS415play et toi?
Après ton backup, est-ce que tu a quelques chose dans la liste Sauvegardes disponibles
Si oui, refait un backup pour vérifier si tu as toujours le message d’erreur.
J’ai un Snap TS-453A
Après le backup la liste des sauvegardes reste vide.
J’ai même essayé de faire 2 sauvegardes à la suite.
Demain matin je vais essayer de mettre une sauvegarde que j’ai avant tout ces soucis et lancer une sauvegarde avec un dossier non vide.
Il serai intéressant d’avoir le résultat de la commande ls -l /share/homes/jeedompi/baclup_jeedom pour que je le compare avec le résultat de la commande équivalente sur mon Synology.
Les formats sont probablement différents et, si ça se confirme, il faudra que je trouve le moyen d’adapter mon code.
J’espère que c’est ce que tu voulais
09H12 j’ai relancé une sauvegarde et en même temps j’ai scruté mon dossier de destination je me suis rendu compte que pendant le « send backup ssh… » le transfert ce faisait et qu’à la fin il supprime le fichier de sauvegarde qu’il est en train d’envoyer…
Le fichier doit faire au final à peut prés 152Mo alors que la limite par défaut et de 500Mo.
Jai même changé le dossier de destination et même soucis. 
Le format de sortie de ta commande ls -l me semble plus conforme à ce que l’on a l’habitude de voir sous Unix/Linux que le format de la même commande mon Synology.
Je vais voir ce soir si j’arrive à adapter mon code pour qu’il puisse fonctionner avec les deux formats.
Il y a tout de même une bonne nouvelle: ton transfert fonctionne
Oui le transfert fonctionne jusqu’au bout dommage qu’il le supprime à la fin bizarre 
En attendant une solution définitive, je te propose de mettre le contenu de la fonction cleanBackupFolder comme ceci:
public static function cleanBackupFolder() {
// $timelimit = strtotime('-' . config::byKey('ssh::keepDays') . ' days');
// foreach (self::ls(config::byKey('ssh::backup::folder')) as $file) {
// if($file['filename'] == '..' || $file['filename'] == '.'){
// continue;
// }
// if ($timelimit > strtotime($file['datetime'])) {
// echo 'Delete backup too old : '.json_encode($file);
// $cmd = self::makeSshCommand('rm ' . config::byKey('ssh::backup::folder') . '/' . $file['filename']);
// com_shell::execute($cmd);
// }
// }
}
Peux-tu me retourner le résultat de ls -l --time-style="+%s" /share/homes/jeedompi/ ?
J’aimerai vérifier que le ls de ton NAS accepte l’option --time-style
Bonjour,
[jeedompi@NASF62441 ~]$ ls -l --time-style="+%s" /share/homes/jeedompi
total 8
drwxrwx--- 2 admin everyone 4096 1617253426 backups_jeedom/
lrwxrwxrwx 1 admin administrators 30 1616840576 @Recycle -> /share/homes/@Recycle/jeedompi/
[jeedompi@NASF62441 ~]$
J’ai fait la modification du fichier comme indiqué tout à fonctionné. Archive crée et sauvegardée dans le dossier voulu.
Super, j’ai une modif du script qui utilise l’option --time-style. Je la poste ce soir.
Super merci
ssh.repo.php.txt (5,3 Ko)
Voilà la nouvelle version qui devrait aussi fonctionner avec ton NAS. J’en ai profité pour finalisé la fonction de rapatriement des fichiers qui ne fonctionnait pas correctement.
Il y a une petite différence dans la fonction de rapatriement par rapport à celle pour le repos samba:
Il y a juste un petit soucis: l’icône tournante affichée sur le bouton de rapatriement ne disparaît pas en fin de rapatriement.
Bonjour,
Merci pour tout, la fonction de sauvegarde s’exécute bien. 
Je rafraichi ma page tout simplement ce qui me permet aussi de rafraichir la liste des sauvegardes disponibles dans la combo des sauvegardes locales.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.