CoolRaoul

Faudrait nous donner plus de détails alors. Tu essaies de te connecter à partir de quel endroit ? (j'imagine que tu n'es pas chez toi pour faire tes tests, à moins que tu les fasses en 3g)

La Freebox : rebootée j'espère? Firewall du syno; activé ou pas?

Dans la section "dossier partagé" du panneau de configuration DSM on ne peux gérer que des droits au niveau global du partage. Pour faire ce que tu souhaites faudra passer par filestation afin d'avoir la possibilité de gérer des droits objet par objet (fichier et ou répertoire). Et pour aller encore plus loin dans la gestion "fine" des droits, on a toujours la possibilité d'activer le support des ACL sur le partage, comme ceci: Panneau de conf->dossier partagé->modifier->windows ACL Savoir que, bien que ce soit nommé "windows acl", les droits mis en place via les ACL sont pris en compte quel que soit la méthode d'acces aux données, même en .ftp

Conseil supplémentaire: pour voir ce qui se passe dans le cas d'un script lancé automatiquement (au démarrage ou en cron), ajouter une ligne de ce genre au début du script: exec >/tmp/<nom_du_script>.log 2>&1[/CODE] Suffira ensuite d'aller voir dans le fichier log ce qui a coincé.

Non non, était bien lancé en permanence. Et en fait le lien "play" a marché une fois en fait, j'ai eu une video pas mal saccadée dans le lecteur mais c'est la seule fois ou j'ai eu un résultat.

Nouvelle version (cf 1er post) La modif pr

"/etc/profile" et "~/.profile" sont sourcés *uniquement* par les "login shells" (qui sont en général des shells interactifs) ce qui n'est bien entendu n'est pas le cas du shell exécutant les scripts situés dans "/usr/syno/etc/rc.d". C'est en outre une très mauvaise idée de mettre des scripts de démarrage "custom" dans des dossiers système de DSM comme celui-ci, dossiers pouvant être wipés à la moindre mise à jour D'autant plus que les devs Synology, dans leur grande sagesse, nous ont réservé /usr/local (au contenu préservé lors des upgrades) pour les customisations personnelles. Par conséquent je t'invite pour commencer à déplacer ton script dans "/usr/local/etc/rc.d" en appliquant les instructions du fichier README.txt situé à cet endroit, à savoir: J'y ajouterait ma préconisation personnelle de te restreindre à utiliser dans ce script une syntaxe shell posix minimale (et donc d'éviter les extensions bash, et y utiliser impérativement le shebang "#! /bin/sh" ) Cette page de man est la bonne référence à utiliser pour savoir ce que tu peux et ne peux pas utiliser dans un tel script. Pour terminer tu dois savoir que tout script de ce type (s'exécutant automatiquement au démarrage, mais cela s'applique aussi aux scripts lancé par cron) doit être écrit en ne présupposant en aucune manière avoir été lancé dans un contexte prédéfini. Cela signifie qu'il est impératif que ces scripts positionnent *eux mêmes* le contexte dont ils ont besoin pour travailler sans faire la moindre confiance à la façon dont ils ont été invoqués. Cela inclut notamment le PATH, le répertoire courant et toutes les variables d'environnement qui peuvent être nécessaire à leur bonne exécution. A la limite tu peux sourcer explicitement /etc/profile (et ~/.profile) dans ces scripts (avec la commande ".") mais je suis pas sur que ce soit le plus propre.

Bon, je pense laisser tomber pour le moment. J'ai voulu tout réinstaller à partir de zéro (histoire d'éventuellement faire un tuto) J'ai donc du refaire un scan Pour cela j'ai constitué un fichier avec les fréquences de mon émetteur (dans /volume1/@appstore/tvheadend/share/tvheadend/data/dvb-scan/dvb-t/) malheureusement me retrouve dans l'onglet "services" de "tv adapters" avec tous les programmes détectés qui ont la colonne "service name" vide et la colonne "channel name" à "unmapped" En plus quand je clique sur "play" , soit ça part en timeout, soit j'ai une fenetre vlc qui s'ouvre et reste désespérement noire. En fait j'ai bien peur que mon petit ds210j ne soit pas assez costaud pour faire tourner ce package (quand je vois les 112meg de vmem du process tvheadend je prend peur). Je m'en vais retourner essayer de faire marcher videostation.

Si ça peut être utile j'utilise un petit script à ma sauce pour manipuler la crontab en toute sécurité Il suffit de maintenir quelque part un fichier crontab contenant uniquement les entrées "perso" Le nom de ce fichier est a substituer dans le script (ligne suivant le commentaire "ligne à modifier a sa convenance") S'exécute en 3 modes: "preview": visualise la crontab générée, lancé par la commande "cronupdate -p" "diff": compare avec la conf actuelle sans l'appliquer, lancé par la commande "cronupdate -d" "apply": applique les modif, lancé par la commande "cronupdate" (sans parametre) Mon script est ici: http://pastebin.com/SmFHxehg

En effet mon exemple était incomplet, Je te conseille pour ne pas risquer des bug tordus de le refaire comme ceci: (avec le "env -") env - /usr/syno/etc.defaults/rc.d/S04crond.sh stop env - /usr/syno/etc.defaults/rc.d/S04crond.sh start

Sans le "env -" les programmes lancés en crontab vont hériter de tout ton environnement actuel (ton PATH, les caractéristiques de ta connexion SSH, etc ...) au moment ou la commande "S04crond.sh restart" est passée Ceci peut créer des problèmes bien velus (j'ai buté pendant une semaine sur un plantage de time backup du a ce genre de sketch) Normalement S04crond.sh devrait se charger de la chose (lancer le cron avec un environnement "nettoyé") malheureusement il ne le fait pas (en fait ça à peut-être été corrigé depuis DSM 4.1, suis pas allé vérifier)

Ajoute a la fin de la ligne wakelan ceci: >> /tmp/wakelan.log 2>&1 ce qui va donc donner 1 15 * * * root /opt/bin/wakelan -m FFFFFFFFFFF -b adresse-ip.fr -p 9 >>/tmp/wakelan.log 2>&1 Et viens poster le contenu de /tmp/wakelan.log des que cela se sera exécuté N'oublie pas aussi qu'il est nécessaire de relancer le cron pour que les modifications soient prises en compte Cela doit se faire comme ceci: env - /usr/syno/etc.defaults/rc.d/S04crond.sh (copier/coller si possible) **EDIT** Et le "env -" n'est pas la pour faire joli !

Bon, ça commence mal déja, cf ici: http://www.nas-forum...entry1319132945 (la remarque sur httpd-vhost.conf-user s'applique également à httpd-ssl-vhost.conf-user) Ca serait bien déja de faire comme c'est expliqué dans le post on ne sait jamais un effet de bord est vite arrivé. Ensuite tu peux simplifier les block virtualhost, en voici un qui marche chez moi, tu peux supprimer dans les tiens tout ce qui n'est pas présent ci dessous: <VirtualHost *:443> ServerName <monhostfile>.<mon domaine> SSLCipherSuite HIGH:MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key SSLEngine on SSLProxyEngine on ProxyPass / https://localhost:7001/ ProxyPassReverse / https://localhost:7001/ </VirtualHost> Utiliser "localhost" a la place de l'ip lan du Syno est aussi une bonne idée

La c'est moi qui ne comprend plus rien. Dans ton premier message tu as écrit "je souhaiterai sauvegarder les données du syno dans un espace de stockage externe, si possible en FTP." Il était donc bien question à ce moment-la de sauvegarder les données du syno à l'extérieur et pas une partition locale non? Et la cible était alors un espace de stockage chez un hébergeur (http://www.swisscent.../online-storage) qui ne supportait que le ftp. C'est à cause de ces limitations que on en est arrivé à la solution Syncback Et maintenant ce que tu nous décris consiste à sauvegarder de données d'un PC windows vers le Syno: cela n'a plus rien à voir. En outre pour faire cela on aurait pu te proposer d'autres de solutions que Syncback, et qui plus est gratuites!

Diaoul: je crois avoir un peu avancé sur le dossier Regarde par ici: http://www.nas-forum.com/forum/topic/29929-tvheadend-manquerait-pas-des-trucs-dans-le-paquet-synocommunity/

Je me suis fait une rapide compil quick and dirty "à l'arrache" (avec optware, je sais ... cest mal) de tvheadend. arrété le paquet Sauvegardé "/volume1/@appstore/tvheadend/bin/tvheadend" dans "/volume1/@appstore/tvheadend/bin/tvheadend.bak" remplacé le tvheadend du paquet par celui produit par ma compil. relancé le paquet A l'arrivée je trouve un onglet supplémentaire qui m'ouvre des perspectives intéressantes pour auto importer l'EPG a partir d'une source xmltv: Ne serait-il pas possible d'ajouter cette option au paquet mis en ligne?

Hélas non, tu ne m'a pas bien compris, VSS ne s'applique pas à la cible mais à la *source* et donc, si comme dans ton cas la source est sur le NAS, il ne s'agit pas de fichiers situés dans des volume *locaux * et donc cela ne marchera pas.

**EDIT** Cela dit je ne vois pas quel est le problème et pourquoi tu insistes à vouloir absolument modifier le php.ini. Pourquoi ne pas essayer l'option 1 telle que je l'avais détaillée dans mon message de juillet dernier?

Ben alors essaie simplement de forcer en lecture seule le .htaccess comme je l'ai indiqué. D'autant plus que le fait qu'un module php puisse modifier le contenu d'un .htaccess me semble un *énorme* trou de sécurité (doit peut-être y avoir de bonne raisons mais franchement je n'arrive pas a les trouver) A ma connaissance, on ne fait *jamais* ce genre de choses. Tu devrais donc également contacter les développeurs de ce module pour voir si ils ne sauraient pas proposer des solutions alternatives. (et je met à part le fait qu'une application php qui impose des modifications de paramètres php *globaux*, comme si elle était seule au monde, me semble aussi un peu limite)

Vérifier que tous les groupes (définis dans "/etc/group") autres que les groupes systemes (gid > 65000 et des poussieres) du Syno sont définis a l'identique sur la plate forme xmbc (même gids, même utilisateurs)

utiliser plutot le chemin complet de wakelan (/opt/bin/wakelan) devrait résoudre les deux problèmes.