CoolRaoul

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

As-tu bien utilisé la notation "$@" dans la dernière ligne du script" rsyncdir" ? Comme ceci; rsync "$@" et non pas rsync $@*[/code] ? [EDIT] Ah non! Trouvé: l'erreur est (encore) dans mon script! Faut remplacer: [code] set -- --archive \ --whole-file \ --update \ --delete \ --delete-excluded \ --exclude="Thumbs.db" --exclude="@eaDir" \ $extra_args \ $source/. $target/.[/code] par [code] set -- --archive \ --whole-file \ --update \ --delete \ --delete-excluded \ --exclude="Thumbs.db" --exclude="@eaDir" \ $extra_args \ "$source/." "$target/." [/code] (les '"' autour de "$source/." et "$target/.") Vraiment désolé

Il s'agit du script qui appelle "rsyncdir" ? Normalement, entouré par des " ça ne devrait pas poser de problèmes On peut le voir?

en effet, pour que l'antishash de fin de ligne joue son role il doit être en ... fin de ligne D'apres le log il ne s'agit *pas* de fichiers commencant par un "." Regarde bien, c'est "./<fichier" et pas ".<fichier>" exemple: "/volume1/Hubic/amsonia/rsync/photos/./Baden Ferrari 2003" Le fichier est "Baden Ferrari 2003" (commence par "B" et pas par ".") dans le répertoire "photos" (le "/." supplémentaire est juste un résidu de la façon dont j'ai passé les arguments à rsync dans mon script) Ce sont donc des dossiers tout ce qu'il y a de plus normaux Faut peut-être renoncer a la propagation des droits dans le cas d'un rsync vers un file system webdav. (en remplacant "--archive" par "-rltgo " (CF la page de man pour la signification de ces switches)

Ca m'a l'air au poil

J'ai bien recu celle notifiant ta réponse-ci il a suffit que je poste pour que ca se répare! Et pourtant j'ai bien vu ce matin qu'il y avait un nouveau message dans Bon, pas si grave après tout mais bizarre quand même

Zut: il me semble que le tuyau vient de se reboucher

Pas dans ce cas, car ce que tu exclue la ce sont les fichiers qui commencent par "." et ce n'est pas le cas du fichier "06 Gala". Il est possible que les fichiers à problème aient un mode (des droits) qui ne soit pas applicables sur un file system "davs" (que donne un ls -ld "/volume1/Hubic/amsonia/rsync/photos/./Baden Ferrari 2003/06 Gala" ? ) Tu peux essayer d'utiliser le rsync natif de DSM aussi pour voir, il est tres complet et devrait marcher aussi bien. Pour cela, enlever "/opt/bin" (pas encore testé) Au passage je viens de découvrir un petite erreur (sans conséquence) dans mon script, faudrait remplacer "[[" par "[" et "]]" par "]" dans le "if" (j'ai corrigé mon post initial) Pas de log par défaut, mais suffit d'ajouter l'option "--verbose" a rsync (et ne pas mettre --quiet) Pour rediriger la trace 'ajouter ">/var/log/rsync-hubic.log 2>&1" a la fin de commande ou mieux, carrément mettre la ligne: exec >/var/log/rsync-hubic.log 2>&1 [/code] en début de script et tout ce qui sera envoyé vers stdout/stderr ira dans ton log Tu as aussi l'option --itemize-changes qui permet de voir pourquoi les fichiers on été transférés Et si tu es joueur, essaie de triturer l'option "--out-format" qui permet un controle complet du format de log. Google m'a trouvé une traduction de la doc rsync en français ou tu trouvera encore plus de détails et ou toutes ces options sont expliquées. Non, pas ici: ce mode est effectif uniquement lorsque on utilise rsync en mode client/serveur. Et d'ailleurs ca serait pas du tout efficace en terme de bande passante. Dans le cas présent, bien que le dossier webdav est un dossier monté via le réseau, rsync se comporte comme si il s'agissait d'un dossier local. aucune idée, Pour ma part j'ai une toute petite volumétrie à synchroniser vers hubic.

Pour ma part j'ai choisi de faire un rsync manuel dans un script appelé en cron, pas d'utilisation de l'outil de sauvegarde syno pour Hubic Important: s'assurer que rsync n'utilise pas l'algorithme "delta-sync" (mais c'est normalement le défaut dans le cas ou la source et la cible sont des chemins locaux, et un montage davfs entre dans cette catégorie)

Comme j'ai écrit ci dessus: "je ne connais pas le bidule"