CoolRaoul

Ben alors, c'est quoi qui ne fonctionne pas? Dans ton message initial tu disais "la tâche en elle-même n'est pas exécutée !" Si le log est rempli c'est bien la preuve que la tache s'éxécute.

Quel est le contenu du fichier log? Peut-être que le script n'est pas exécutable? (en ligne de commande, faire un chmod +x du fichier) Je suis en 5.1 Je ne me souviens plus trop comment fonctionne le gestionnaire de taches en 4.3 en fait, mais en 5.0 et + on se retrouve au final avec une utilisation du cron Mais l'article que tu cites explique *justement* la manière de faire en utilisant le cron! Tu t'y prend comment toi alors? **EDIT** Me suis trouvé un acces à un DSM 4.2, je vais pouvoir reproduire exactement ta situation.

Ah non, là c'est pas tout à fait pareil: ici tu logge *uniquement* la sortie standard de la commande php, alors qu'avec mon approche ce sont les sortie standard *et d'erreur* de *tout* le script (y compris php bien entendu) Ta ligne shebang est incomplète déjà (mais c'est vrai que je m'était mal exprimé en y faisant référence) Et pour la redirection fait utiliser l'approche que j'ai conseillée. La bonne syntaxe est donc #!/bin/sh PATH=/bin:/usr/bin:/usr/syno/bin [ -t 0 ] || exec >/volume1/web/Moulin/logE.log 2>&1 php /volume1/web/Moulin/ecod2sql.php La je ne saurais dire, je ne suis pas spécialiste php.

Assure-toi d'être bien connecté avec le compte "root" (même mot de passe que le compte admin). La commande à taper est: tail /var/log/dms.log Ça va afficher les dernières lignes du fichier. Ensuite nous donner le résultat. Mais si ça n'affiche rien il ne te restera plus qu'a contacter le support Synology. Je suppose que tu as déjà essayé de simplement redémarrer le NAS sinon?

Comme dans 99% des cas ou on rencontre ce symptôme, il est fort probable que ce soit une un problème de "PATH". Il faut *toujours* spécifier le PATH dans les scripts, et plus particulièrement ceux qui sont susceptibles d'être exécutés en cron (ce qui est le cas via le planificateur de taches). Un shell interactif exécute "/etc/profile" et "$HOME/.profile" ce qui n'est pas le cas de ceux lancés par cron. Par suite, comme sous DSM le binaire php est dans "/usr/syno/bin", ajouter en début de script (après la ligne shebang, "#!): PATH=/bin:/usr/bin:/usr/syno/bin Et puisque tu y es, pense à ajouter la génération d'un fichier log quand le script s'exécute en mode non interactif, comme ceci: [ -t 0 ] || exec > /tmp/runmoulin.log 2>&1 ou bien, plus traditionnel mais plus verbeux (et pas tout à fait équivalent mais c'est sans importance): case $- in *i*) : ;; *) exec > /tmp/runmoulin.log 2>&1 ;; esac comme ça, si d'autres erreurs se présentent tu pourra en voir le détail et ça simplifiera le diagnostic

DMS c'est le proccess du package Mediaserver Pour avoir une piste, faudrait commencer par aller voir (en se connectant en root par ssh ou telnet) ce que contient son fichier log ("/var/log/dms.log")

Et si tu avais commencé par expliquer précisément ce que tu cherches a faire? Tel que spécifié, le premier "cp" va copier sur la cible tous les fichiers dont le nom correspond à "*Toto*.*" Maintenant, veux-tu en fait copier *tous* les sous-répertoires de "FromSeedbox" et les fichiers nommés "*Toto*.*" qui s'y trouvent, ou simplement *tous* les sous-répertoires de "FromSeedbox" avec *tous* leurs fichiers, quel que soit leur nom? (ou toute autre combinaison...)

Si, dans les deux commandes de ton exemple, tu remplaces "cp" par "rsync -u" ça fera exactement ce que tu souhaites. **EDIT** pour info: fserv> rsync --help | grep -e --update -u, --update skip files that are newer on the receiver

Essayer plutôt avec rsync alors (/usr/syno/bin/rsync) , encore plus économique en I/O avec les bonnes options.

Il existe encore des équipements avec des ports ethernet ne gérant pas le "Auto MDI-X" ? Car ça fait un bail que je ne suis plus posé la question câble croisé vs câble droit (d'autant plus qu'il suffit qu'un seul des deux équipements de chaque extrémité soit compatible pour que ça fonctionne)

Vu que ce n'était pas spécifié (il n'était question que de d'une "certaine fonction web" ) on ne pouvait pas deviner Oui: https://www.synology.com/fr-fr/knowledgebase/tutorials/493

En connexion root via SSH ou telnet, regarder le contenu de "/var/log/upstart/httpd-user.log". Il y a des chances d'y trouver une piste.

L'*endroit* c'est justement cette section "présentation" ou nous sommes. Suffit de poster un message en texte libre. Mais bon, on peut dire que tu es présenté maintenant Par contre cette question-ci aurait mieux sa place ici: NAS-Forum → Support des logiciels Synology → Partage de fichiers et privilèges → Win/Mac/NFS A part ça je te conseille de faire ceci: créer sur le NAS un compte *non administrateur* au libellé identique à celui utilisé sur ton PC Windows et avec le *même* mot de passe que sous Windows. toujours sous Windows, aller dans "Panneau de configurationTous les Panneaux de configurationGestionnaire d'identification" et supprimer toutes les entrées relatives au compte "admin" initial du NAS ainsi que celles du compte admin alternatif que tu as créé ensuite. déconnecter et reconnecter la session windows la connexion au NAS en en partage fichier se fera avec ce compte. (si ça ne marche toujours pas ou si tu as besoin de précisions complémentaires enchaîne avec un nouveau sujet dans la section dont j'ai donné le lien ci dessus)

Merci du feedback, le Cloud a peut-être du avoir des vapeur passagères. Tu verras à l'usage KeyPass est un super outil.

Je n'ai jamais rencontré le genre de dysfonctionnement que tu décris (mais quand j'utilisais CloudStation c'était uniquement pour des accès en lecture) Déjà faut bien comprendre que Keypass ne garde pas le fichier ouvert: à l'ouverture il constitue une copie en mémoire de la base kdbx et referme le fichier aussitôt. Au moment de la sauvegarde il fusionne les modifications qu'il a dans sa copie en mémoire avec celles du fichier sur le disque. Toutes ces opérations sont bien entendu protégées par un système de verrou pour éviter des écritures simultanées. Je pense qu'il est possible que ce soit CloudStation qui interfère dans ton cas. Mieux vaut sans doute s'en tenir (comme moi) à un accès direct en partage réseau et laisser Keypass s'occuper de la synchro.

A partir du moment ou tu utilises la version 2 de Keypass (dite "pro") tu n'as pas à t'inquiéter : chaque sauvegarde est en fait une synchro. Donc aucun risque qu'une sauvegarde d'un PC écrase des nouvelles entrées créés avec l'autre. En plus il gère automatiquement un historique au niveau de chaque entrée. Le mettre dans un dossier synchronisé par CS à l'avantage de disposer de ce fait d'une historisation de ta base Keypass mais rien ne l'oblige. Dans mon cas j'accède à mon Keypass en local directement en SMB/CIFS à partir de plusieurs postes Windows. A distance je me connecte en webdav, aussi bien via l'application Android que par un Keypass installé en mode portable sur une clé USB. **edit** A noter que depuis mon message initial j'ai laissé tomber dscloud à cause de défauts rédhibitoires pour moi mais ce n'est pas le sujet ici.

Dedikam j'ai testé leur service et mon expérience n'a pas été enthousiasmante (mais comme on dit ... "your milleage may vary") On en a discuté dans ce

Merci d'avoir participé. En effet: il semble qu'une première passe récupère les stats de tous les fichiers et la deuxième mouline dans la database. Mais pourquoi donc? Je ne demande qu'un rapport "global" dont les données utiles se résument a l'espace libre/occupé de mes deux disques. Pas besoin d'aller interroger tous les fichiers pour ça (et ça ne le faisais pas en 5.1) (Je sais bien que je peux faire ça avec un malheureux "df" reformatté dans un csv et chargé dans un tableur mais j'aimerai comprendre)

Vous avez sans doute remarqué que DSM 5.1 à introduit un nouvelle version de l'outil d'analyse d'occupations disque: l’analyseur de stockage ("Storage Analyzer") Pour ma part j'avais un banal rapport programmé hebdomadaire qui se contentait d'une simple option activée: "espace disque". Rien de bien compliqué et en effet ça ne prenait que quelques secondes à s'exécuter. Depuis l'arrivée de la nouvelle version je viens de constater que son exécution déclenche une activité forcenée des disques et semble prendre des heure. Tout ça sans même aboutir à un résultat (rien dans l'historique des rapports, et plus de réception du mail "Le rapport d'utilisation de disque a été généré") Cette nuit j'ai rebooté mon NAS vers 1h30 alors que la commande "/usr/syno/synoreport/synoreport -report volumes" consommait allègrement CPU est I/O disque. Je suis à la recherche d'autre témoignages histoire de déterminer si c'est ma configuration qui est en faute ou si le problème est plus général. Donc, est-ce que que quelqu'un pourrait exécuter un rapport avec la configuration ci-dessous: et m'indiquer l'ordre de grandeur du temps de génération du résultat (si résultat il y a)? Merci d'avance NB: je viens d'en relancer un à la main mais je ne suis pas sur d'avoir la patience d'attendre qu'il se termine. Une trace du process me révèle qu'il est entrain de faire des stat64() de *tous* les fichiers de *tous* mes dossiers partagés avec une occupation CPU scillant entre 60 et 85% (pour un rapport global, je vous demande un peu ...) En complément je m’aperçois que cet outil génère maintenant un fichier .db à chaque run (dans le sous répertoire "synoreport/volumes/AAAA-MM-DD_HH-MM-SS" de son répertoire de logs. Le tilmestamp de ce .db confirme un temps d'exécution de l'ordre de 3H30!

Ca aurait quand même été mieux de poster dans la bonne section (ici c'est "NAS-Forum → A propos de ce forum → Suggestions", ce qui n'est pas du tout en phase avec le sujet), mais n'étant pas modérateur je ne suis pas habilité à déplacer le fil.

Pas forcément idéal si le poste utilisé pour se connecter est chez un pote, ou à son boulot, et qu'on ne veut (peut) pas modifier sa conf réseau.

Euh ... c'est déjà le cas avec la substitution $(date ...) Possible mais gaffe aux potentielles erreurs de frappe, toujours risqué quand on fait des delete en masse. A part ça, faut juste ajouter une 2eme ligne après le "wget": find <chemin_dossier_backup> -name "*.ics" -mtime +30 -print0 | xargs -r -0 rm ("-print0" et "-0" pourraient être omis mais ça permet de ne pas partir en vrille en cas d'espaces dans les noms de fichiers) ou encore plus simple (j'oublie souvent l'existence de cette option "-delete" de "find"): find <chemin_dossier_backup> -name "*.ics" -mtime +30 -delete

Le planificateur de taches intégré sait le faire: Dans le nom du fichier, insérer: $(date "+%Y%m%d")qui sera substitué par la date au format "AAAAMMJJ"

Si tu n'est pas à l'aise avec unix, même pas besoin de passer en ligne de commande, Tu peux commencer par créer sous l'interface d'admin DSM une tache programmée avec le contenu suivant: /usr/syno/bin/wget -O <chemin_dossier_de_sauvegarde>/<fichier_sauvegarde>.ics "<url>" En remplaçant respectivement le <chemin> par un truc du genre "/volume1/mon_partage/backups/", le <fichier> par disons "sauvegarde_agenda.ics", et <url> par l'url privée de ton agenda google (à récupérer dans les paramètres de l'appli web google agenda) Dans un deuxième temps, on pourrait envisager quelque chose de plus compliqué avec gestion de l'historique des .ics (par exemple en ajoutant la date et l'heure dans le nom du fichier ics local) mais faudra penser à purger aussi.

Une conf "reverse proxy" (bidouille conf apache, haproxy ou nginx, se référer aux tutos respectifs) permet cela très simplement.