CoolRaoul

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)

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é.

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.

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.

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?