CoolRaoul

C'est le comportement attendu, et ca signifie que le fichier est bien lu. Ne marche pas non plus ici (j'ai la même redirection que toi) Tu sais, le mieux serait que tu nous balance l'intégralité de ton fichier de conf, histoire de voir exactement ce qui coince. Parce que la on avance à petit pas...

et qu'a donné le test pour vérifier qu'il est bien lu? [edit] Si c'est le cas n'oublie pas que la partie "host" de l'url que tu tapes dans ton navigateur doit être étre strictement identique à l'argument de la clause "ServerName" de ton fichier de conf pour que ça marche.

Ben justement la redirection que tu constates laisse a penser que le fichier n'a pas

Sous DSM, la racine du serveur web est "/var/services/web" (qui est un lien vers, dans la plupart des cas, "/volume1/web" ) La réponse est donc: cd /var/services/web[/code]

C'est que la conf proxy n'est pas prise en compte, Dans ton fichier de conf apache, as-tu bien une section comme ci dessous? <VirtualHost *:> ServerName dsm.mondomaine.fr ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> La ligne "ServerName" doit correspondre a ton sous domaine.

Alors pourquoi avoir écrit ceci: "Pourtant je n'ai pu obtenir mon dossier web (avec les différents sous dossiers) qu'aprés avoir installé phpmyadmin" ? Mon objectif était de simplement répondre à ton affirmation erronée: "De plus PhpMyAdmin contient tout (apache, mysql= c'est le principe du wamp, ou du lamp (cf ci dessous)" ==> PhpMyAdmin ne contient *ni* apache *ni* mysql. Et il sert uniquement à administrer la base MySQL et pas du tout "la partie serveur apache interpretant le php". Je me vois désolé de devoir à nouveau contredire ce qui est dit: dès que DSM est installé Apache *et* MySql le sont aussi car ils en font partie intégrante. Le manuel, page 92, explique justement comment "configurer" (activer si tu préfère) le site web. Il ne s'agit pas d'une "installation" car les composants requis sont *déjà* installés (et c'est comme cela qu'il fait comprendre l'expression "nativement"). Apache, lui, est d'ailleurs déja utilisé pour gérer l'interface d'admin (port 5000). L'activation du "service web" a pour effet d'activer une seconde instance Apache sur le port . C'est par l'intermédiaire de cette instance que l'on accède à phpMyAdmin des que celui ci est installé. (pour la petite histoire l'activation de webdav a pour effet de démarrer une 3eme instance d'Apache , dédiée) Et toutes ces instances s'appuient sur les *mêmes* binaires. Ta mémoire te joue probablement des tours, DSM ne demande pas l'installation du paquet phpmyadmin quand on coche cette case (je parle d'expérience et d'ailleurs tous les membres de ce forum pourraient le confirmer). Au passage, il suffit d'imaginer un instant que, si Apache n'était pas installé, on ne pourrait pas accéder à l'interface d'admin DSM étant donné que cette dernière s'appuie sur Apache justement. Tout ce que je peux affirmer c'est que dans la boite ou je travaille on ne trouve pas du tout ce genre d'argumentaire "alambiqué". On y considère (comme beaucoup d'autres) que passer de 2.2.X en 2.4.X ne se justifie pas et donc on préfère assurer. Pas besoin de me faire un cours magistral , je connais tout ça (je suis un peu dans le métier depuis largement plus d'une vingtaine d'années...). Je voulais juste dire que le choix de la version Apache 2.2.22 par Synology, qui est la plus stable et universelle à ce jour, me semble pertinent et ce n'est pas un hasard que peu de sites on fait le choix de passer à la branche supérieure. Maintenant, si tu a as explicitement besoin de fonctionnalités Apache 2.4.X, c'est une autre affaire, mais sous DSM il va te falloir pour cela faire cohabiter deux serveurs apache de version différentes (l'interface d'admin nécessite l'apache 2.2 "natif DSM") et ça peut être un peu casse gueule pour quelqu'un qui "débute sur NAS". PS: je suis désolé de sembler faire ces mises de façon un peu systématique au point mais il faut comprendre que, ce forum étant entre autres destiné à donner des informations juste et fiables aux utilisateurs Synology, ce ne serait pas correct de laisser les lecteurs potentiels lire (et surtout croire) des choses inexactes. PS.2: l serait peut-être temps de terminer ce fil qui est parti en complet HS par rapport au titre initial ("Phpbb") puisqu'il n'est plus du tout question de phpbb depuis un bon nombre de messages.

Pas obligatoire: on peut utiliser un service de DNS dynamique comme justement MyDS de synology qu'il dit avoir configuré Non plus, sauf si besoin explicite (utilisation DS file sur android par exemple) Il dit justement l'avoir fait. (bien noter que ce n'est pas nécessaire si on a une ip fixe mais pour mettre en oeuvre le reverse proxy il faut disposer d'un nom de domaine ou utiliser un service de redirection DNS qui supporte les sous domaines, ce qui est le cas de myds). Plutôt commencer par le port 5000 seul et ensuite affiner en fonction des besoins exacts Pas normal ca (à moins que Free Mobile bride certains ports, mais je n'ai nulle part entendu parler de ça).

Faut tester l’accès a distance a partir d'une connexion à distance (tu peux cependant vérifier de chez toi en utilisant une par exemple connexion via smartphone en 3G ) Ton routeur dlink de doit pas appliquer la redirection de port lorsque la source de la connexion est coté réseau interne (ou alors tu as carrément oublié de configurer la redirection de ports pour le Syno sur le routeur)

Faut redémarrer apache pour que les modifs soit prises en compte: /usr/syno/etc/rc.d/S97apache-user.sh restart[/CODE]

Sur le Synonogy, le service web ne devient actif des lors que l'on a coché l'option "activer web station" dans le panneau de configuration, icone "service webs" Il est très probable que l'installation du package PhpMyAdmin ait pour effet de bord d'activer cette option Non, phpmyadmin est tout simplement une application écrite en PHP permettant d'administrer en mode WEB une (ou plusieurs) bases MySQL. Et pourtant ... Il est exact que La 2.4.2 est la dernière version dans la branche 2.4 Toutefois, DSM embarque un Apache de la branche version 2.2, et la 2.2.22 est bien la dernière version dans cette branche (voir ici) Et cette branche 2.4 est loin d'être largement adoptée jusqu'ici (seulement 0.1% des sites) En outre la branche 2.4 apporte des modifications dont l'impact est non trivial par rapport a la 2.2, particulièrement sur les mécanismes d'authentification et de controle d'accès. Les caracteristiques manquantantes sont probablement due aux différence entre 2.2.X et 2.4.X tout simplement. De la à parler d'un "equivalent" apache ...

c'est le même

En complément. Tu as écrit: Autant que je sache phpbb n'est *pas* présent par defaut dans les paquets fournis par Synology

Bon ... si tu es si sur de toi alors, bonne chance

Ton probleme est plus une question spécifique PHPBB qu'une question Synology/DSM. Par conséquent, tu aurais bien plus de chances d'obtenir de l'aide en le soumettant sur le forum phpbb dont j'ai donné le lien plus haut Cela dit tu devrais trouver pouvoir trouver réponse à tes questions ici

Pourquoi pas installer un proxy sur ton syno et accéder aux serveurs Evernote à travers ce dernier ? Celui-ci par exemple: http://www.glype.com/ .

Commence simple en testant uniquement la connection sur le port 5000 (interface DSM sans SSL) Et n'oublie pas de rebooter ta Freebox pour que les redirections soit prises en compte Tu peux partir de quelque chose comme ça: PS: dis-nous aussi comment tu t'y prend pour faire le test de connexion "de l'extérieur" ? Connection 3G? Utilisation d'un proxy externe? Demander l'aide d'un ami ?

Es-tu sur d'avoir *effectivement* constaté une modifications de droits ? Si tu a un peu de temps à perdre, et pour en avoir le coeur net, il t'est possible de tracer les appels a l'API windows de ton programme Office en utilisant Process Monitor. (penser à activer un filtre sur le process office à surveiller). Tu visualisera ainsi exactement ce qui se passe "sous le capot".

Parler de "bug" pour la suite Office me semble un peu exagéré: il semble que les programmes Office cherchent à vérifier les droits des fichiers (ce qui necessite le droit "lire permission") avant de tenter une écriture (il peut y avoir de légitimes raisons à cela) Les autres programmes que tu as testé se posent moins de questions et effectuent directement l'écriture dans le fichier. Et la "parade" ne consiste après tout qu'à donner les droits "lire permissions" en supplément aux droits d'écriture. Ca ne me semble pas si cher payé.

Donc on peut conclure que maintenant, apres avoir appliqué sur "Dossier C" L'ACL qui pour le groupe "G" donne tous les droits "lire" et "ecrire" ainsi que "Lire Permission", ça marche comme souhaité?

Pour avancer un peu, faudrait que tu nous montres l'ACL que tu as positionné sur le dossier parent, l'ACL d'un des fichiers Office à problème et enfin celle d'un des fichiers qui marchent .

C'est ça, et même tu peux te limiter à ne mettre que le PATH minimum nécessaire à l'exécution de ton script, du genre: PATH=/bin:/usr/bin:<repértoire de la command wakelan> un fois que cette ligne est dans ton script, si il marche quand lancé "à la main" il marchera lorsque lancé par cron Me semble pas que le cron busybox ait un log par défaut. Mais rien ne t'empéche d'ajouter a la fin de tes entrées crontab un truc du genre: "> /var/log/<nomlog>.log 2>&1" ou bien: ">> /var/log/<nomlog>.log 2>&1" si tu veux éviter d'écraser le log précédent (penser a nettoyer dans ce cas) par exemple: /usr/syno/scripts/boot.sh > /var/log/cron-boot.log 2>&1

Essaie de rajouter "en dur" la définition du PATH ("PATH=...") au début du script "/usr/syno/scripts/boot.sh" J'en profite pour marteler un de mes mantras : *toujours* positionner le PATH dans les scripts shell. On n'a par principe aucune garantie de la valeur de ce dernier (héritée de l'environnement du process père) au moment ou le script s'exécute. Par exemple, dans ton cas ca m'étonnerait que le PATH hérité via crond contienne le répertoire ou est situé ta commande "wakelan"

Euh moi c'est CoolRaoul, pas Piwi hein