CoolRaoul

Si tu as du mal a trouver la réponse à ton problème (et pourtant c'est une des question les plus souvent posées sur le forum: ce ne sont pas les fils sur le sujet qui manquent), le mieux est d'attendre l'arrivée de DSM 5.0 après la fin de la phase beta en cours. Tu pourras te connecter à distance beaucoup plus simplement, en utilisant (comme c'est déja possible avec DSFile) utiliser quickconnect pour te connecter à DSM ou directement à filestation via un navigateur PC.

Oui: le script me semble un peu bancal mais on constate bien qu’après le "stop" tous les process dhcp sont arrêtés et à la suite du "start" ils sont a nouveau actifs avec les mêmes paramètres. Note aussi que ça va changer en 5.0: DHCP devient intégré à DSM et n'est plus sous forme de package, les scripts de start/stop seront ailleurs.

Me suis mal exprimé: ce qui m'a interpellé c'est comment on peut avoir un processus *dans* un dossier. A part "/proc", dans un dossier on trouve des fichiers (possiblement exécutables) , d'autres dossiers et éventuellement des sockets unix ou fifos, mais parler de "processus"?

Pas apres le "stop":

J'ai vérifié et en effet les scripts font des erreurs (peut-être un peu buggés ?) fserv> ps -ef |grep dhcp root 20491 1 0 09:19 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20492 20491 0 09:19 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20548 19770 0 09:20 pts/0 00:00:00 grep dhcp fserv> /var/packages/DHCPServer/scripts/start-stop-status stop Deleted 0 keys from file /etc/synoinfo.conf kill: can't kill pid 20492: No such process fserv> ps -ef |grep dhcp root 20611 19770 0 09:20 pts/0 00:00:00 grep dhcp fserv> /var/packages/DHCPServer/scripts/start-stop-status start sh: 1: unknown operand sh: 1: unknown operand sh: 0: unknown operand sh: 0: unknown operand sh: 2281: unknown operand rm: can't remove '/etc/dhcpd/dhcpd.conf.leases': No such file or directory rm: can't remove '/etc/dhcpd/dhcpd-leases.log': No such file or directory kill: can't kill pid 20717: No such process fserv> ps -ef |grep dhcp root 20724 1 0 09:20 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20725 20724 0 09:20 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20761 19770 0 09:20 pts/0 00:00:00 grep dhcp Il est bien stoppé pour moi (cf les commandes "ps") A quoi constates-tu que DHCP ne s’arrête pas de ton coté?

C'est quoi "/PWNED" ?? (Google ne m'a pas vraiment aidé)

Emacs + Tramp alors! (mais la "learning curve" risque d'être un peu ardue si tu ne connais pas)

Merci pour l'info. Pour moi le principal est que ce soit réglé lors de la sortie de la version définitive de DSM 5

Non, la seule option possible c'est winscp qui permet de faire du scp, avec filezilla ca sera au mieux sftp et sur le syno, par sftp, on ne peux accéder qu'aux fichiers situés dans les dossiers partagés **edit** cf: http://winscp.net/eng/docs/scp Remarquer que dans la plupart des situations sftp est préférable, mais la on est dans un cas particulier.

Ah ca c'est exact, c'est juste pour modifier des fichiers existants (dans une liste prédéfinie à déterminer), ponctuellement

"Config file editor" Le support du package a été interrompu mais on peut le récupérer ici

Ben non, ça reste inexplicable: je ne vois aucune explication pour qu'un script sous le compte root fasse l'erreur "Permission denied" en ouverture de "script_cam.sh.log".

Vu que les messages précédents du fil on prés d'un an, et que plusieurs versions de VideoStation on été publiées depuis, ça m'étonnerait beaucoup que ce soit le *même* problème (juste des symptômes similaires) As-tu bien installé VLC et cochant l'option "plugin" dans le menu présenté lors de install?

Heureux que ca marche Par contre l'erreur ci-dessus me plonge dans un abime de perplexité: le script étant exécuté en tant que root (qui a, de fait, *tous* les droits), l'erreur ci dessus est absolument inexplicable

Merci de prendre le relai

Ne *jamais* utiliser notepad pour éditer un script unix! Si tu tiens à utiliser une appli Windows, à la limite prendre notepad++ configuré comme cela: Sinon, "vi" directement sous DSM (rustique mais sans surprises)

On n'est pas a l'abri d'une faute de frappe dans la fenêtre du planificateur de tache (tu nous y as habitué faut dire ) Vérifie Sinon tu peux aussi essayer d'ajouter une ligne forcant la génération de log *dans* le champ "exécuter la commande" planificateur, comme ceci: Ensuite pour tester la tache à volonté, passe par le bouton "exécuter": et ensuite regarde le contenu de /tmp/task.log

Le décodage "a la volée" dépend du modèle de NAS, du type de media, du client, ... Bref c'est assez compliqué Heureusement il y a une page sur le site Syno qui résume tout ça: http://www.synology.com/fr-fr/support/faq/577

Oups, c'est moi qui me suis trompé ce coup ci Remplacer: [ -t 0 ] || exec /tmp/script_cam.sh.log 2>&1 par: [ -t 0 ] || exec >/tmp/script_cam.sh.log 2>&1 (il manquait un ">")

Le chmod est à faire une seule fois et pas à mettre dans le script ce n'est pas rm _rf mais rm -rf ("-" et pas "_") je te conseille d'ajouter la ligne suivante juste en début du script (juste apres la ligne "#!...") [ -t 0 ] || exec /tmp/script_cam.sh.log 2>&1 comme ça tu aura une trace d'exécution dans "/tmp/script_cam.sh.log" ou tu pourra consulter les éventuelles erreurs je te conseille de d'abord commencer lancer la script à la main pour tester son fonctionnement.

Ca m'a l'air bon, Comme l'a fait remarqué Fravadona, rm -rf /volume1/cameras/sam/* supprime le contenu de "sam" mais pas "sam" lui même Pour supprimer "sam" *et* son contenu: rm -rf /volume1/cameras/sam Mais faudra peut-être le créer vide ensuite: mkdir /volume1/cameras/sam (dans ce dernier cas, faudra peut être ajuster les droits de sam à coup de "chown" et "chmod")

Non: #!/bin/sh Plutôt "script_cam.sh" Mieux vaut éviter les espaces dans les noms de fichiers, c'est permis mais on ne sait jamais. D'abord le rendre exécitable avec la commande: chmod +x script_cam.sh Simplement mettre le chemin complet du script dans le champ commande du formulaire, exemple: /volume1/perso/scripts/script_cam.sh.

Dans le planificateur de tache la ligne "shebang" est sans effet, c'est toujours "/bin/sh" qui est utilisé Personnellement je préfère mettre mes commandes dans un script séparé et mettre juste l'appel de ce script dans le fenêtre du planificateur de tache, mais chacun fait à sa façon.

Quand on extrait un tar en étant connecté "root" les fichiers sont recrées avec exactement les mêmes droits (user, groupe, modes) qu'à l'origine. Ce n'aurait donc pas été nécessaire.

Redémarre le NAS déja Mais après, si ça merdoie toujours c'est qu'il doit y avoir d'autre dégâts et tu risques devoir a réinstaller DSM (en tous cas je ne vois pas d'autre solution dans l'immédiat)