Page : index.php?v=d&p=backup
Jeedom_version : 4.0.49
Uname : Linux Maugrey 4.19.97+ #1294 Thu Jan 30 13:10:54 GMT 2020 armv6l GNU/Linux
Message :
Bonjour,
Lors d’une sauvegarde sur un partage SAMBA hébergé sur un NAS le smbclient se ferme après quelques secondes avec le message : cli_push returned NT_STATUS_IO_TIMEOUT, la sauvegarde ne fait que quelques Mo et n’est pas complète.
Après analyse des logs et recherche il s’avère qu’il y a un timeout par défaut de 20 secondes sur le client SMB : smbclient
En exécutant smbclient manuellement en ligne de commande en augmentant le timeout à 120 secondes avec l’option « -t 120 » la sauvegarde s’effectue correctement.
Serait-il possible de modifier l’appel à smbclient avec cette option lors de la sauvegarde, SVP ?
Pour information, il existe quelques posts sur le forum à ce sujet sans solution.
Cordialement
.
Bonjour,
J’ai eu le même problème de timeout lors de la copie en SMB sur mon NAS.
Vous pouvez éditer le fichier suivant : /var/www/html/core/repo/samba.repo.php
Chercher la ligne :
return system::getCmdSudo() . 'smbclient ' . config::byKey('samba::' . $_type . '::share') . ' -U "' . config::byKey('samba::' . $_type . '::username') . '%' . config::byKey('samba::' . $_type . '::password') . '" -I ' . config::byKey('samba::' . $_type . '::ip') . ' -c "' . $_cmd . '"';
Changer en :
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 . '"';
PS : je suis en v3.3.39 donc ce fichier n’est peut-être pas le même.
Bonjour,
Je viens de remettre la ligne chez moi suite à une réinstallation.
En demande d’évolution, j’irai plus loin :
Il faudrait rendre ce point paramétrable.
Par exemple ajouter une entrée ici :
Avec la clef samba::backup::cmdtimeout correspondante en bdd et une valeur par défaut à 20 (puisque c’est sa valeur d’origine).
J’ai bien entendu laissé la partie backup parce qu’on peut très bien imaginer vouloir un timeout différent en fonction du type de commande envoyée.
Bonne soirée
Olivier
Si le timeout par défaut ne suffit pas c’est que cote NAS le seul est pas OK, ou il est en veille ou autre.
Après pourquoi pas proposer de pouvoir régler le timeout dans jeedom a voir ave. Loic
Bonjour,
Je suis partiellement d’accord avec toi.
En effet, le problème peut venir de chacun des équipements entre Jeedom et le NAS.
J’ai pu notamment remarquer de grosses latences lorsque je suis en Wifi depuis que j’ai installé en Raspbian Buster.
Je suis depuis passé en RJ45 mais la configuration de ma maison m’impose de passer par un CPL dont la connexion est moyenne également.
Cependant, je suis d’accord sur le fait qu’il serait bien de pouvoir rendre ce paramètre configurable, c’est un peu le sens de ma précédente réponse.
@Loic, quel est ton avis ?
Aussi, en attendant et pour éviter de devoir modifier un fichier du core de jeedom à chaque mise à jour, j’ai juste modifié le partage pour ajouter l’argument -t 120 dans le partage :
Salut à tous,
Je relance de 1 ce sujet, j’ai hélas le meme problème 
La modif dans le .php a fonctionné mais à chaque mise à jour majeure, même problème…
Merci pour vos retours 
Bonjour,
Je suis moyen pour dans l’idée oui c’est bien dans la pratique ca fait encore une option de plus que très peu d’utilisateur vont comprendre pour un cas vraiment spécifique…
Bonjour,
J’ai le même soucis mais je pense qu’il s’agit chez moi d’un problème de qualité réseau. Faut dire que je cumule les risques
1 raspberry à la cave
WIFI
2 access point au rez.
CPL
3 module CPL au 1ier
câble ethernet
4 hub
câble ethrnet
5 Synology DS415 Play
J’ai régulièrement des timeout lors des sauvegardes.
Un ping lancé en même temps qu’un backup m’a montré qu’il y a des pertes de paquets durant le transfert du backup.
N’ayant pas trouvé de solution du côté de samba, j’ai décidé de créer une classe repo_ssh qui me permet de faire les transferts en ssh.
Il est encore trop tôt pour me réjouir mais j’ai pu effectuer plusieurs sauvegardes sans problème.
Si vous êtes intéressés:
- Le fichier ci-joint doit être copié en /var/www/html/core/repo/ssh.repo.php
- Il faut un compte sur le synology (ou autre équipement) qui permette de se loguer en ssh (shell autre que « nologin » dans /etc/passwd
- Il faut mettre en place les clés ssh pour mettre de se loguer depuis le compte root du jeedom sur le synology avec le compte du point précédent sans avoir à saisir un password.
- Je crains que le fichier ssh.repos.php ne soit supprimé lors d’une mise à jour de jeedom. Il est donc préférable de garder une copie au chaud.
- dans jeedom: Réglages → System → Configuration → mise à jour/market puis activer et configuer « Ssh »
ssh.repo.php.txt (5,6 Ko)
J’avais le même pb depuis quelques temps, du coup j’utilise le plugin Cloudsync Pro en ftp et j’en suis satisfait
Bonjour, curieusement, le même problème vient d’arriver subitement sur mon Jeedom Smart en 4.1 :
Comme vous pouvez le voir, les sauvegardes sont complètes jusqu’au 12 août, puis j’ai droit au time out tous les jours sauf le 15 août.
Je viens de changer le timeout à 180 s et c’est passé aujourd’hui.
En surveillant la sauvegarde sur mon Nas, je vois que le fichier met beaucoup de temps à arriver. Mon réseau fonctionne très bien, débit parfait et cette sauvegarde Samba fonctionne depuis plus d’un an !
J’ai l’impression que quelque chose ralentit le transfert depuis Jeedom, avant ça allait très vite. En quelques secondes, le fichier était sur mon Nas.
759 s pour ma dernière sauvegarde !
Je vois des solutions de contournement, comme utiliser d’autres techniques de sauvegarde mais cette solution me convenait parfaitement. Je ne sais pas si vous avez des idées pour corriger la source du problème
Salut,
@Loic, Je partage ton point de vue, c’est vrai que c’est dommage de consommer du temps pour un soucis qui semble plutôt marginal.
D’autant que des solutions de contournement existent à la lecture des messages.
Peut être que l’ajout dans la doc de mon astuce peut suffire ?
En effet, depuis que j’ai ajouté le « -t 120 » dans le champ [Backup] Partage, je n’ai plus aucun soucis.
@Dark_Kermit : Pour trouver la source du problème, il faut étudier les changements dans ton architecture avant et après l’apparition du problème.
- Mises à jour Jeedom ou NAS
- Emplacement des équipements
- Type de communication réseau (Wifi, cable, RJ45,…)
Ton réseau fonctionne très bien tout le temps ? Peut-être que tu as d’autres maintenances qui tournent en même temps que ta sauvegarde.
Tu peux essayer de modifier l’heure de sauvegarde, c’est un cron :
Bonne journée
Merci pour ton retour.
Mon installation n’a pas du tout changé après le 12 août. Aucun changement côté Jeedom, Nas, Box,…
Suite à une suggestion, je suis passé à la sauvegarde ftp par plugin CloudSyncPro, cela fonctionne très bien et très vite.
D’ailleurs, je croyais que le core Jeedom permettait à un moment le ftp, cela semble avoir disparu en cours de développement.
C’est vrai que c’est bien pratique pour résoudre le soucis de timeout lors des backups, malheureusement ça doit être refait à chaque mise à jour.
Je n’ai pas l’impression d’être dans un cas particulier non plus. Jeedom et Synology connectés en filaire sur un switch avec 2m de câble. Jeedom fait uniquement Jeedom, le Synology fait uniquement serveur de fichier, et n’a pas de mise en veille. Pourtant sans le timeout, ça ne fonctionne pas à chaque fois.
Je peux tout à fait comprendre Loic :
Cependant, -t est un argument totalement transparent qui est par défaut à 20 quand il n’est pas spécifié. Je ne pense pas que le mettre en dur dans le code à 180 ou 120 fera échouer les sauvegarder pour ceux à qui ça fonctionne déjà.
Bonjour,
Relisez la proposition suivante qui a été faite deux fois dans ce sujet et vous ne devrez plus rien faire à chaque mise à jour; de plus vous pourrez choisir votre timeout.
Je vais marquer ceci comme solution, cela sera plus visible.
Effectivement, je n’avais pas compris l’astuce en lisant ce message.
Merci
Bonjour,
Il semblerait que le timeout soit passé à 120 secondes en alpha.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.