CoolRaoul

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.

Je viens de découvrir, pour une raison que j'ignore que les alias et les ports supplémentaires que j'avais défini dans le portail des applications ont étés effacés: D'autres auraient-il constatés le même phénomène? Je me demande quelle peut bien en être la cause.

Home Server est justement l'exception (que j'avais oublié, mea culpa) Et, de toutes façons, une exception (intégration des partages home server dans les bibliothèques seven) ne peux jamais être invoquée pour confirmer une règle (interopérabilité des bibliothèques avec les partages réseau *en général*). N'as-tu pas remarqué que cela ne fonctionne pas non plus entre deux machines Windows 7 (qui sont bien toutes les deux sous OS Microsoft)? Donc avant de faire une requête à Synology faudrait quand même commencer par s'en prendre à Microsoft. Apparemment Microsoft ne souhaite pas (pour une raison que j'ignore) rendre publique l'API permettant l'interconnexion/l'acces distant des informations d'indexation entre deux machines sur le réseau (car c'est en fait ce point qui est la cause de l'impossibilité constatée). Et si il ne l'ont pas fait jusque'ici (les bibliothèques existent depuis Vista) ça m'étonnerait fort que ça change maintenant. Mais rien ne t’empêche d'aller poser la question sur un forum Microsoft.

dans "site ip or url" faut ajouter "/<nom du partage>" (ce qui donne "<hostname syno>/test" dans ton cas) ***EDIT** Et tu peux même utiliser des sous dossiers ("<hostname syno>/test/subdir" etc )

Et pourquoi ne pas nous avoir expliqué tout ça dès le début? La solution est d'activer webdav sur ton NAS. Tu configure netdrive pour créer une lettre de lecteur mappée sur le partage webdav que tu a choisi pour héberger ta sauvegarde et ça devrait le faire.

Ah, je cromprends mieux, mais dans ce cas tu as mal posé la question. Ce ne sont pas "les dossiers stockés sur un NAS Synology ne sont pas compatibles avec les bibliothèques de Windows 7" mais bien les bibliothèques de Windows 7 qui ne sont pas compatibles avec les partages réseau (et donc avec *tous* les NAS, pas seulement ceux de Synology) Par conséquent le problème est coté Windows et pas coté NAS. Il existe un petit freeware qui répond partiellement à ton besoin qui permet justement d'ajouter n'importe quel dossier aux bibliothèques (mais attention: toutes les fonctions ne sont pas gérées, notamment l'indexation). Tu le trouvera entre autres ici: http://www.softpedia...rary-Tool.shtml (malheureusement il ne semble plus supporté, le site original de l'auteur n'est plus accessible)

Sans blagues? On ne peut pas indiquer à ce logiciel dans quel dossier situer sa sauvegarde? Et il ne sait faire ses sauvegardes uniquement via ftp (pas smb ni nfs?). Par conséquent, lui donner pour cible un chemin unc (nas<dossier partagé) ou un disque réseau, n'est pas possible non plus? Faut vite nous donner son nom qu'on ne fasse pas l'erreur de l'acheter. Blague à part, j'imagine qu'il est au minimum possible de lui indiquer le *nom* du fichier de sauvegarde, et alors peut-être accepte-t-il des noms avec des "/" . Dans ce cas essayer de donner comme nom un chemin relatif (dans le cas de l'exemple, donner comme nom "test/<masauvegarde>") et il ira donc mettre son backup dans le dossier partagé "test" sans avoir besoin de "naviguer" dans "test"

Tu voudra bien m'excuser de ne pas tres bien comprendre: lors de la question précédente l'appli se nommait déja "Prestashop" et la solution que j'avais donné était fonctionnelle. Et là, vu ta question ci dessus ("pour la gestion des mon site sous prestashop"), bien qu'il s'agisse *toujours* de "Prestashop", la solution ne s'applique plus? Comme je l'avais déja dit a l'époque, le php.ini est écrasé lors d'une mise à jour de DSM. Apparemment il semble, d’après ce que tu nous décrit, qu'il le soit aussi lors du redémarrage du Syno. Donc je persiste : la bonne approche reste le .htaccess. Et pour éviter qu'il soit écrasé un bon "chmod -w" de ce dernier et du répertoire qui le content devrait faire l'affaire (ou mieux: "chown root" suivi de "chmod go=w", toujours pour le fichier *et* le répertoire)

Le serveur ftp du syno pr

La question a déja été posée. Une simple recherche sur le forum, comme ceci: t'aurait directement trouvé cette réponse: PS: je conseille fortement de choisir l'approche basée sur le .htaccess