CoolRaoul

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

Finalement Damien

Non, tu prend le fichier dont je donne le lien comme départ et tu y ajoute les lignes "defname" correspondant aux chaines que tu as ajouté dans ton channel.con Je ne vois pas vraiment comment je peux être plus détaillé que dans mes explications du premier post Et attention a utiliser un éditeur supportant l'UTF8 (meme notepad de windows sait faire mais mieux vaut utiliser notepad++) A propos, de quelle "mise à jour" parles-tu ?

http://fr.wikipedia.org/wiki/XMLTV Non: VideoStation va récupérer l'EPG dans le flux TNT mais on n'a pas la maîtrise de la fréquence de cette opération. En outre l'EPG intégré au flux TNT est (du moins en France) assez limité (2 ou 3 jours d'avance il me semble). D'ou l’intérêt de mon script. Non plus, et tout le monde se plaint de ce défaut (ainsi que de l'impossibilité de pouvoir modifier les enregistrements programmés). Je pense que Synology intégrera ces fonction dans une future version (fait prendre en compte du fait que que VideoStation est un composant relativement jeune )

Eviter OpenPhoto sur un NAS entrée et milieu de gamme, c'est un gouffre en perfs! (testé et désapprouvé pour ma part)

Attention: je ne propose rien du tout, je me contente d'essayer expliquer comment DSM gère les droits de façon différentes, sur le dossier partage d'une part, et pour pour les accès via PhotoStation de l'autre. Il faut aussi savoir que PhotoStation nécessite que le compte unix utilisé par apache "nobody" (ou le groupe eponyme) ait accès complet (rwx donc, au sens droits unix) aux dossier "photos" et, pour encore compliquer les choses, que DSM ne permet pas d'utiliser les ACL sur ce partage. (Personnellement, je n'utilise pas PhotoStation, je m'y suis juste un peu intéressé pour répondre à des questions sur ce forum).-

Les droits d’accès via l'application photostation en http sont complètement indépendants des droits du partage "photo" (je sais, au premier abord, ça surprend) J'en ai parlé ici: Donc tu peux restreindre les droits du partage "photo" en les mettant aussi restrictifs que tu veux (uniquement "admin" si tu le souhaite) et pourra toujours gérer séparément les acces pour les utilisateurs utilisant photostation.

Ben c'est expliqué dans le (paragraphe "Notes au sujet du fichier "xml2epg.conf")

moi aussi Si on n'utilise pas l'infra SPKSRC jusqu'au bout (génération du spk) faut d'abord rassembler les libraries dépendantes (je suppose dans ../gnutls/work-88f6281/install/, etc ...) et ensuite soit les mettre dans le bon répertoire à l'arrivée soit passer par un LD_LIBRARY_PATH. J'ai eu la flemme... Tant qu'a faire "crade", j'ai utilisé mes petits scripts perso qui, sur mon nas, mettent tout dans /site/(local|bin|lib|etc...) (/site est un "mount -bind" vers un répertoire de /volume1, "à la optware"), je génère un .tar avec des chemins relatifs que j'extrait sur mon syno) et ainsi je mutualise les .so à l'arrivée C'est pas tres industriel (c'est pourquoi je garde mes scripts pour moi) mais ça fonctionne .

A la lecture de ce fil je me pose une question: pourquoi est-t-il si difficile (en tout cas je n'y suis pas parvenu) en partant de la page "produits" du site officiel Synology de savoir quel CPU

Ah non, j'ai pas eu le temps Justepus compiler un wget fonctionnel pour mon archi avec mes propres scripts, mais faire un spk me faudra prendre un peu de temps

Dans ce cas suffit de désactiver/réactiver les fonctions correspondantes dans l'interface DSM et les lignes seront automatiquement régénérées.

et surtout (le cron DSM est tres sensible à ça) attention de séparer les champs par des tabulations et pas par des espaces!

Par principe tous les crontabs sont différents en fonction des sauvegardes programmées, des jobs timebackup, etc