CoolRaoul

Les différents modèles de freebox font du proxy WOL (si configuré). Pour les autres, même d'éventuelles méthodes détournées ne peuvent s'appliquer de façon fiable car les entrées de la table ARP expirent assez vite, quelques minutes typiquement.

En fait j'ai dis ça car à ma connaissance aucune box ni routeur envoie spontanément un "paquet magique" lors d'une simple tentative de connexion externe vers une IP du LAN déclarée dans la table de redirection de ports (faudrait déjà qu'elle en mémorise l'adresse MAC de façon permanente pour ça)

Je ne pense pas que ce soit suffisant: il se réveille uniquement sur réception d'un "Magic Packet" (broadcast, UDP, port 0, 7 ou 0 et contenant l'adresse MAC du NAS)

Faudrait qu'un cador du debug http/javascript (F12 dans la plupart des navigateurs) puisse analyser en live ce qui se passe dans ce genre de situation pour avoir des pistes.

Mon petit grain de sel pour témoigner que je fais face (depuis toujours il me semble) au même phénomène, particulièrement quand la connexion doit traverser un proxy. @crunch ne serait-ce pas dans ce cas également que tu le constate? A noter également qu'une fois loggé la réactivité est tout à fait correcte.

Pas constaté chez moi, mais faut dire que mon script de démarrage dans "/etc/local/etc/rc.d" est en réalité un lien symbolique vers un fichier situé ailleurs. C'est peut-être grâce à ça que j'ai été épargné.

Parfait Éventuellement si ça t’intéresse je pourrais t'expliquer plus tard comment rendre cette clé SSH dédiée exclusivement aux commandes "synoservice --pause samba" et "synoservice --resume samba". C'est pas indispensable mais un peu plus propre, en particulier dans le cas comme ici d'une clé "passwordless".

Mettre des quotes autour du chemin de la clé, sinon l'espace entre "program" et "files" pose problème: plink -i "C:\Program Files\PuTTY\adminkey.ppk" etc ...

Utiliser l'IP du NAS, et ça aiderait si tu nous montrais nous la commande utliisée.

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