CoolRaoul

Voilà pourquoi j'ai écrit être d'accord en ce qui concerne la forme. Mais quand on n'est pas débutant ça gonfle un peu de de retrouver avec une réponse semblant s'appuyer sur des mots-clés plutôt que sur le contenu des résultats de tests détaillés fournis (vécu)

OK sur la forme, par contre sur le fond, je ne suis pas loin de penser comme lui: mes dernieres expériences avec le support n'ont été particulièrement positives.

Comme ça:

Ca doit contenir du shell, tout simplement Dans le champ script commencer par "set -x" suivi de la commande "ping ..." On aura alors forcément la trace de l'exécution dans la sortie d'erreur CF ci-dessous:

je ne comprend pas cette phrase as-tu bien utilisé le menu "action" -> "afficher le résultat" du planificateur de tache pour vérifier comment la tache s'est exécutée? https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/system_taskscheduler

Ok, je répond aux deux questions alors: Les deux approches sont possibles. C'est comme on veut. Plus exactement la zone "tache" est destinée à contenir un script shell, on peut se contenter de mettre juste la ligne de commande qui invoque le script externe . Pas forcément: si on l'invoque par "sh /chemin/du/script" ce ne sera pas nécessaire. Sinon, il est aussi possible de se contenter d'enregistrer le NAS chez Synology et activer le heartbeat via le panneau de conf DSM. Pour vérifier son état: https://account.synology.com/fr-fr tu sera prévenu par mail des pertes et reprises de connectivité (tu n'auras pas la précision à la minute pres par contre, à voir si c'est vraiment indispensable)

Et tu veux qu'il se passe quoi quand ça arrive?

Pourquoi parles-tu de Windows 7 , 8 etc ???? Je suis sous windows 10 (pas pro) et je serais surpris que, sur ce point, le fonctionnement soit différent sous home. M'étonnerais pas que tu n'ai pas testé exactement dans le même contexte. Enfin, bref, à part ça, je constate que tu es parvenu à épuiser la patience de @Lucien77 @Mic13710 (qui pourtant en ont vu d'autres!) et les autres participants à ce fil. Mon tour est venu de lâcher prise. Bonne continuation.

je n'ai jamais dis le contraire. J'ai pris le temp de tester (ce que tu aurais pu également faire de ton côté avant d"émettre des hypothèses): en fait ça n'a aucun rapport avec le fait d'être ou pas sur un compte admin. C'est uniquement quand on se connecte, dans le contexte de sa session Windows, au NAS avec une compte (username) *différent* du celui de la session windows qu'un mapping (net use) est créé (peut-être également si le mot de passe est différent, j'ai pas testé jusque là) Donc dans ton cas, puisque apparement c'est de cette façon que tu pratiques (username NAS <> username Windows) la solution donnée par @Fenrir me semble la plus rapide. Suffit juste d'ajouter juste un "/yes" à la commande net use pour se passer de confirmation: net use * /delete /yes

Ca à toujours fonctionné comme ça pour moi sur tous les Windows que j'utilise, que ce soit à domicile ou au travail Je suis connecté à mon Windows sur un compte simple utilisateur avec les même identifiants (user/pass) que mon compte DSM et je n'utilise pas le mappage de lecteur (n'en ai jamais eu le besoin), uniquement les chemins UNC (format "\\nom\..."). Me semble que c'est une pratique courante. Les compte admin Windows et du NAS je les réserve pour des actions nécessitant des privilèges, ponctuellement donc. Si on relit ton premier message, il n'était pas question de serveur distant que je sache je cite: Ce qui rend encore plus inexplicable d'avoir dit un peu plus haut que tu ne connaissais pas cette méthode

Bien entendu: je le fais régulièrement et ça marche aussi bien avec juste le nom du serveur ou avec un chemin complet.

Comme pour toute connexon à un dossier réseau partagé sous Windows Et il existe plusieurs méthodes: démarrer -> exécuter -> "\\<monas>\<partage>\<chemin>" Dans la branche "réseau" de l'explorateur, en dépliant l'entrée correspondant au NAS Ou directement en tapant dans le champ adresse de l'explorateur:

Merci de me prendre pour un newbie ... J'ai écrit "dans l'explorateur" et pas "dans le navigateur".

Je ne pense pas que cette solution s'applique à tous les cas. Je suis actuellement connecté dans une session windows 10, via l'explorateur j'ai bien accès à mon nas en utilisant sur mon compte DSM et malgré ça, voici ce que "net use" dans une boite de commande me répond: $> net use Les nouvelles connexions seront mémorisées. La liste est vide.

Normalement faudrait ouvrir un ticket de support chez Syno. Mais mes deux dernières expériences m'ont franchement découragé. Je laisse ça aux plus patients que moi (d'autant plus que, la commande n'étant pas documenté et donc pas officiellement supportée, ça leur serait encore plus facile de botter en touche)

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