CoolRaoul

En l'absence de chemin complet ce n'est le répertoire de putty qui est cherché mais le répertoire courant (%cd%). Le mieux est de mettre le chemin complet de la clé (comme par exemple -i "%USERPROFILE%\NAS.ppk") dans la ligne de commande

Je ne comprend pas ce qui peut provoquer la fermeture de l'invite de commande. Si tu la tape directement dans une fenêtre (sans passer par un script .bat ou .cmd): "démarrer" -> "exécuter" -> "cmd" et là dedans tu saisis la commande, qu'est-ce qui s'affiche?

Si je dois changer de navigateur des que je veux éditer un mes messages, j'ai peur de me lasser assez vite Le support IPB a-t-il une piste sur ce problème? Bon je découvre que j'ai ce problème sur *tous* les navigateurs Je suis derrière un proxy, c'est sans doute lui qui déconne... J'ai trouvé un workaround via des copier/coller à partir d'un nouveau post que j'annule ensuite, pas top mais mieux que rien.

Faut pas utiliser putty mais plink C'est pas "putty" mais "plink" qu'il faut utiliser si tu veux le scripter (dans un .bat/.cmd par exemple). Et c'était dans mon message (je me cite "sous PC pour le faire en ligne de commande c'est "plink"") Inutile de passer par un profil ("-load") et fichier d'input ("-m commande.txt"). Faire plutôt comme ceci: plink -i <chemin de la clé .ppk> root@<ip_du_nas> /usr/syno/sbin/synoservice --pause samba" (pourquoi ne t'appuie pas sur les exemples que je donne? )

C'est bien "root" qu'il faut utiliser, par contre sous DSM l’accès root en direct par mot de passe est désactivé. La bonne approche est de faire une authentification par *clé* (comme je l'ai d'ailleurs évoqué: "en particulier au niveau de la gestion des clés pour que l'authentification puisse se faire sans interaction utilisateur" ) et non par mot de passe.

Aie, zut, si ce n'est pas reproductible à volonté nous voila bien.. Je vais effacer le cache du navigateur alors. **EDIT** Pas mieux Par contre pas de problème avec Firefox, c'est avec Chrome que ça coince.

Faut passer par ssh, pas par telnet (sous PC pour le faire en ligne de commande c'est "plink" qui fait partie du package Putty) Sans entrer dans les détails (en particulier au niveau de la gestion des clés pour que l'authentification puisse se faire sans interaction utilisateur, tu devrais trouver facilement des tutos la dessus par ailleurs), ca devrait ressembler à ceci: plink root@<host_nas> "/usr/syno/sbin/synoservice --pause samba"

Bon ca s'aggrave, voila que ca me le fait en répondant à un fil! (ici même par exemple) ennuyeux

Si le besoin ce limite à cela, cela ne ne vaut-il pas envisager d'utiliser le service de partage multimedia intégré à Windows? (sous réserve bien entendu que les appareils "picoreurs" supportent le DLNA)? Ca se configure via le lecteur Windows Media. (J'avoue ne pas avoir creusé cette approche en particulier sous Windows 10 mais risque rien d'essayer.

Alors la je suis sec, reste à vérifier une fois de plus les autorisations du partage coté windows (partage avancé -> autorisations -> tout le monde) L'idéal serait de pouvoir valider avec un autre PC sur le même LAN pour déterminer si le problème est plutot coté client (NAS) ou serveur (PC) Tu peux aussi aller voir dans l'observateur d'évènements Windows (eventvwr) si par chance tu ne tombe pas sur une erreur éclairante. Pas d'autre idée pour le moment.

Me semble un peu aventureux (bien qu'en principe fonctionel) d'utiliser des noms de partages avec un espace ("Disque I" ici) Le mieux serait de partager sans espace, par exemple comme cela: et refaire la manip Ce qui est important, plus que la confirmation du fait que ce soit partagé, est le *contenu* de la colonne "Nom Partage": Voila qui démontre que le dialogue CIFS NAS <-> PC est fonctionnel déjà.

J'ai la même erreur lorsque le chemin du dossier est invalide. Il s'agit du champ "Dossier" du formulaire du montage de dossier distant, il doit être de la forme \\<nom_ou_IP_du_PC>\<nom du partage> Sur le poste Windows, exécuter dans une fenêtre de commande la commande "net share" pour vérifier que c'est bien le même nom qui est utilisé (colonne "nom partage")

Voila qui serait étonnant vu que CIFS est le protocole de partage réseau standard de Windows. La raison de l'échec doit être ailleurs: quelle est le message d'erreur exact?

Essaie de refaire *sans* cocher curl, tu verra que ça marche aussi. Pour ma part je n'utilise rien de tout ça: quand j'ai besoin de mettre en place un script à exécuter en tache de fond je préfère choisir un language plus adapté que php. L'alternative à curl que j'ai proposé via la commande "/usr/syno/bin/php" (que je le rappelle je n'ai pas testé) doit permettre de faire exécuter ton script php *directement* par l'interpréteur php, sans l'overhead inutile (même si c'est peanuts en terme de CPU) qui consiste (via curl, firefox ou autre) de sous-traiter au serveur apache l'appel au moteur php. Si il reste des points qui t'échappent dans ce qui précède, ce n'est pas bien grave, l'important est que ça fonctionne d'une façon ou de l'autre.

Ma main à couper que cette option n'est pas nécessaire: la commande "curl" ("/bin/curl") existe nativement sous DSM est est utilisable indépendamment de l'activation de l'extension "curl" de php. (à tester malgrè tout). Je pense qu'il est également possible d'éxécuter directement le fichier php avec la commande éponyme, autrement dit /usr/syno/bin/php /volume1/web/recup_statuts_xml.php Ca élimine le besoin de faire une requête http. (ca aussi c'est à tester, je ne suis pas spécialiste de php)

Essaie "/usr/bin/nginx" alors

Je viens de m'apercevoir que lorsque j'édite un message existant, je ne dispose plus de la barre d'outil d"édition complète mais uniquement ceci: **EDIT** Apparemment c'est pas systématique (ici c'est bon par exemple)

@yongbi même si le commentaire fait référence à DSM6, Il ne fallait pas commenter comme tu l'as fait le bloc de code ci dessous: #SYSNGINX=/bin/nginx #NGINX=$BASE/bin/nginx #cp --update --archive $SYSNGINX $NGINX car alors la variable shell "NGINX" est vide et par suite la ligne: $NGINX "$@" && echo >&2 "nginx: $action" commence directement par les arguments ("-p ..." en l’occurrence) ce qui explique l'erreur constatée En complément, je n'ai pas de DSM5 sous la main mais il est aussi possible que "cp --update --archive" ne fonctionne pas. Le plus simple est alors de remplacer les 3 lignes précédentes par: NGINX=/bin/nginx En gardant à l'esprit qu'il faudra remettre la version originale en cas de migration sous DSM6

Pour une raison qui m'échappe, "synonet --wake" a cessé de fonctionner chez moi et d'autres. Solution: réutiliser ce vieux script Perl qui fait l'affaire comme j'en ai parlé ici: https://forum.synology.com/enu/viewtopic.php?f=90&t=116493&p=475318#p474953

Ca n'a pas changé depuis les versions précédentes A mettre dans "/usr/local/etc/rc.d" en suivant les préco ci dessous, extraites du guide développeurs: ***EDIT*** Ah, j'oubliais! Depuis DSM6 il y a une autre méthode, en passant par le planificateur de taches. On peut y créer une "tache déclenchée" avec comme déclencheur "démarrage":

C'est parce qu'ici on est dans "Bien démarrer avec votre Synology" -> "Installation, Démarrage et Configuration" La section "Divers" aurait été sans doute plus appropriée alors.

Es-tu sur que ça puisse avoir un rapport avec ton NAS Synology?

Non, d'abord je suis plus lent à me décider, en outre honnêtement ne n'ai pas besoin des fonctions et perfs supplémentaires que ça pourrait m'apporter (à un seul bémol pres: l'USB3 qui me manque un peu pour pouvoir faire des sauvegardes sur support externe qui dépotent un peu).

Hier soir il était en stock (cf mon screenshot) Tout a du partir rapidement.

Oups, les pb de certificats ça peut être velu, Peut-être que @gaetan.cambier aura une idée.. En tout cas si ça coince aussi quand tu passe en direct, c'est pas forcément la partie reverse proxy qui est en cause