CoolRaoul

Chez moi le dossier "@download" est créé sur le *mème* volume que celui ou est situé le dossier spécifié comme destination de téléchargement dans downloadstation. (j'ai les cibles de téléchargement volume2 et c'est également la qu'est le dossier "@download") Je suis très étonné que cela soit différent chez toi. Faudrait nous expliquer quelle peut être la différénce, en terme de fragmentation entre télécharger dans un dossier puis faire un "move" (ou un link) ou télécharger directement dans le dossier cible. M'étonnerait fort que cela soit fait sous forme de copie, à partir du moment ou reste dans le meme volume je pense que les devs de downloadstations se sont contentés d'un hard link et donc aucune "fatigue" inutile. **EDIT** Je m'apercois que tes points 2 et 3 (et donc mes remarques portant sur ces derniers) n'ont plus lieu d'être du moment que tu constates in fine le même comportement que moi pour le point 1.

Comme cela a déja été dit Photostation a sa propre gestion des dossiers Aussi bien les droits d'acces que les indexes sont gérés de façon indépendante du reste du systeme . J'ai un peu détaillé le mécanisme Attention, depuis le début du fil la question ne porte pas sur mediaserver mais bien sur Photostation. Ce n'est pas la même chose.

C'est le forum qui ajoute automatiquement des liens commerciaux sur les posts en fonction de mots clés. (quoi que dans le cas présent le lien entre les mot clés et la pub me laisse perplexe...) Faut bien un peu de revenu pour faire vivre "nas-forum" Dans ce cas peux-tu te connecter sur https://myds.synology.com/ et nous dire ce qui est affiché dans le cadre que j'ai entouré de rouge:

Quel fichier "vhost" ?

Je vois: tu es la victime de cette horreur qu'est le "parcours réseau" dans le monde Windows. Tu pourra lire la description d'une situation similaire a la tienne. La visibilité d'un serveur dans le "voisinage réseau" est d'une non fiabilité légendaire. Pour accéder à ton NAS dans l'explorateur, je ne peux que te conseiller de créer un raccourci vers "192.168.0.222" (tu peux aussi utiliser le nom a la place de l'IP) sur le bureau, dans le dossier "favoris" ou la où bon te semblera, et ne plus (jamais) faire confiance au "voisinage réseau":

Mais je ne me souviens plus comment ça se présente en dsm3 Ben ca dépend de ton usage et de tes besoins, mais pour l'instant,comme notre probleme porte sur le port 7001 (et on a besoin du 443 pour atteindre le reverse proxy), on va s'en tenir a ces deux-la

N'aurais-tu pas perdu l'affectation du port 7001 à file station en https dans le portail des applications du panneau de configuration? (ça m'est déja arrivé ce genre de gag)

Reverse proxy, Appliquer ce tuto en y appliquant les adaptations que j'ai données ici et Si j'ai le temps je proposerai à Patrick une version re-actualisée du tuto afin d'en faire une mise à jour (le problème est que j'ai un peu de mal avec la syntaxe Wiki :-/ ). (Au cas ou tu as du mal a mettre le truc en place je viendrai poster dans ce fil une ré-écriture des explications pour que tu n'ai pas a jongler entre toutes les sources)

Dis nous alors précisément ce qui ne marches pas (de façon la plus descriptive possible à savoir: "je fais ceci, il se passe (ou s'affiche) ceci[,alors que je lm'attendais à cela]") En ensuite si tous voulais bien répondre à *chacune* des questions ci dessous (je fait l'hypothèse que tu es sous Windows étant donné que tu ne nous l'a pas spécifié): Dans le voisinage réseau du poste connecté en ethernet, tu vois le NAS? Que donne un "ping 192.168.0.222" a partir du PC connecté en ethernet que donne démarrer->exécuter->\\192.168.0.222 repondre aux meme 2 questions précédente dans le cas du PC connecté en wifi

Est-ce bien coché la? Et au contraire, n'aurais-tu pas coché ceci:

Alos la je ne sais plus quoi dire, j'utilise une configuration de VirtualHosts de même genre sans avoir ton problème Dans ta situation, j'essaierai de mettre en commentaire tout le bloc VirtualHost concernant "ServerName monadresseadmin.no-ip.org", il n'y aura donc plus de référence au port 5001 dans ta config Ensuite redémarrer apache et voir ce que ça donne

J'imagine que tu a fais ce que j'ai conseillé dans mon message précédent: qu'est que ça à donné?

Tu n'as pourtant même pas évoqué avoir utilisé filestation dans ton message! Mais tu as bien acces à tout ça dans filestation! En utilisant le menu contextuel "propriété" sur un dossier partagé, on a accès la gestion des droits globaux de ce dernier comme dans "Dossier partagé", et en le faisant sur un sous dossier, on a ses droits locaux. Donc ce que tu veux faire est tout a fait possible en utilisant filestation. Par contre, vouloir attribuer des droits (pour un utilisateur donné) plus restrictifs à un sous dossier qu'a son dossier père n'est pas une approche habituelle (c'est en général plutôt le contraire que l'on fait, ou bien on utilise deux dossiers "frères") et je sens que tu va bien t'emm** si tu tiens a procéder comme cela (et ce ne sera pas possible sans passer par les ACL en plus)

Alors pourquoi nous parler des redirection de ports? Ce ne fait qu'embrouiller les choses. Tu aurais quand même détailler tout ça dès le premier post, franchement... Bon, ça serait bien de pouvoir d'abord de valider la config de ton NAS en utilisant Synology Assistant sur un PC connecté en filaire. Tu pourrais nous faire ça stp? A la limite mettre une IP en dur au Syno, sans passer par le DHCP de la FreeBox, simplifierai le tout aussi.

Oui: c'est expliqué dans le premier post ainsi que dans #entry1319155918"'>celui la

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