CoolRaoul

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)

Et pourquoi as-tu remplacé "usr" par "user"??? Tu devrais faire un copier/coller, ça éviterait ce genre d'erreur. Alors la je ne comprend pas, avec le "cd /user/..." qui à forcément planté, tu devrais avoir le message d'erreur suivant: ls: TaskScheduler: No such file or directory Ou bien tu as bien tapé "usr" et pas "user" et donc tout est correct. Vérifie bien et, pour gagner du temps, si il s'avère que c'est n'est bien que le répertoire TaskScheduler qui à été effacé (et uniquement lui) tu trouvera ici une archive tar (TaskScheduler.tar.gz) de ce dossier Pour l'extraire tu vas te mettre dans le répertoire ou tu as déposé cette archive (TaskScheduler.tar.gz) et tu tapes *exactement* la commande suivante: tar -C /usr/syno/synoman/webman/modules -xvzf TaskScheduler.tar.gz ensuite tu redémarre le NAS

Aie, pas facile de de suivre ce style ampoulé.. Cela dit, et en réponse à: Je n'ai pas indiqué de *fichier* mais un *répertoire* ("le dossier par défaut des taches programmées") Il ne s'appelle pas "taskscheduler" mais "TaskScheduler" (les systèmes unix sont sensible à la casse) Plutôt que "vi", serait utile de savoir ce que donne la commande "ls -l TaskScheduler" Si le résultat montre que c'est vide, vu que j'ai la même version de DSM, je pourrai te fournir une archive tar du répertoire "TaskScheduler" à décompresser dans ce dossier (il n'y a pas de fichier binaires exécutable dans ce dossier à cet endroit donc pas de problème de compatibilité entre modèle Syno différents). Sinon (si rien n'a été effacé à cet endroit) c'est peut-être que quelque chose à été supprimé ailleurs et la je sens la grosse galère pour trouver où. Une réinstallation de DSM risque d'être la seule option.

je confirme, sshfs pour juste transférer des fichiers c'est carrément démesuré (et de plus je serais surpris que ça ait été implémenté sous DSM). Pour compléter ce qui à déjà été dit juste au dessus, un petit rsync ou sftp en ligne de commande et ça roule.

#!/bin/bash cd /volume1/cameras/sam4 rm -rf * Bigre, tu es un fou furieux toi! As-tu imaginé les dégats possibles si le "cd" échoue? Je viens d’ailleurs de de vérifier: sur cette version de DSM, pour le compte root, le dossier par défaut des taches programmées est "/usr/syno/synoman/webman/modules/TaskScheduler". Si justement ton "rm" à échoué (une simple faute de frappe peut suffire) et voila que tu as scratché tout le contenu de ce dossier. Ca pourrait expliquer ce que tu constates. Sinon; il n'y a pas de "bash" dans "/bin" sous DSM, c'est "ash" ou "sh" (mais dans le planificateur de taches la ligne "shebang" est sans effet, les commandes sont exécutée par /bin/sh de toutes façons)

Le principal est que ce soit dispo lors de la sortie de la version définitive (ne t'ont pas donné de date j'imagine?) Sinon la page de FAQ que j'ai mentionnée ne sera plus exacte (et dans tous les cas serait judicieux que le pré-requis d’installation de ce package y soit mentionné).

Piwi: tu n'as pas oublié pas hein?

Le tableau du WIKI ne semble pas donner les codes pour les leds des disques, donc je ne suis pas surpris qu'elles restent actives (cela dit, la langue de Goethe ce n'est pas ma spécialité)

D'apres le wiki du forum allemand je me demande si il ne faut pas faire un "echo" par led Autrement dit: echo 6 echo 7 echo B echo 2

Ah je comprend mieux, ça permet d'introduire délai de 30 secondes. Je ne m'y serai pas pris ainsi mais en effet ça doit marcher Je préfère que le script se rappelle lui-même avec un paramètre, me semble plus lisible Un truc dans ce genre: #!/bin/sh # PATH=/bin:/usr/bin case $1 in CALLBACK) sleep 60 echo 67B2 >/dev/ttyS1 ;; *) $0 CALLBACK <&- >/tmp/$(basename $0).log 2>&1 & ;; esac Mais je reconnais que cela ne résoud pas ton problème

Me semble bien tarabiscoté ce script! (NB: j'ai pas acces a la source originale car bloqué par mon proxy pour le moment) Il y a une raison de générer dynamiquement des commandes dans un autre fichier ("/tmp/Power-LED-OFF") puis ensuite l'exécuter en backgroud?

Pas vraiment non Un petit schema serait utile, Me semble comprendre entre les lignes que le but serait de d'avoir un débit théorique d'un gigabit entre TV et NAS: dans quel but? Un flux vidéo HD passe déja dans une bande passante de 100mbit/s.

Ah merci pour les infos, en fait je savais juste qu'il fallait le laisser inactivé et j'ai pas trop creusé plus avant en m'en tenant la.

Oui et alors? Le serveur multimedia n'est pas incompatible avec le fait d'avoir des répertoires partagés. Ou bien faudrait décrire avec plus de détails quelles méthodes et avec quels appareils tu as prévu que tes amis accèdent à tes videos, jusqu'ici c'est un peu brumeux pour moi.

Si tu partage des vidéos en DLNA (en activant le serveur multimedia) elle seront accessible sur le réseau local sans authentification. Tes amis pourront les visualiser à partir de leur portables. Dans ce cas, pas besoin d'activer le compte "guest" (ce qui est d'ailleurs déconseillé en général).

Ah tu downloade d'abord et ensuite seulement regardes ce que ça contient? Sinon, vu que les nouveautées sont affichées *directement* sur la page de download (lire à partir de "What’s New in DSM 5.0") , je ne comprend pas comment tu as pu les louper

Pas d'inquiètude: ce que tu as paramétré sous le compte admin sont des parametres *globaux* du NAS, il ne sont pas liés au compte. Met un mot de passe bien costaud sur le compte admin et tu sera tranquille. L'important, des que ton NAS sera accessible de l'extérieur assure toi d'avoir activer le blocage d'IP (comme ça a été dit)