CoolRaoul

Oui c'est long (mais c'est plus le *nombre* de fichiers que leur taille cumulée qui est déterminant: 10Gb composés d'une dizaine de fichiers videos seront indexés bien plus vite que le même espace occupé par quelques milliers de mp3.) et c'est essentiellement ça qui consomme des ressources. Il y a aussi la génération des vignettes (pour les images et les videos) qui consomme également/ Les packages dont tu peux éventuellement différer l'activation (pour lisser la charge) sont VideoStation et PhotoStation. Les autres autres peuvent être activés sans impact notable à mon avis.

Faut laisser l'indexation initiale aller à son terme, ensuite ça se calmera tout seul.

https://www.synology.com/fr-fr/support/developer#tool "Guide des développeurs tiers" "Ce guide fournit des détails sur la création de paquets pour les produits Synology DiskStation. Il présente la structure, la compilation, la sélection du langage, l'interface utilisateur et la publication du paquet - tout ce dont vous avez besoin pour commencer à créer un paquet." Pour simplement compiler, s'en tenir à la section "Compile Applications". NB: La toolchain doit être installée sur une plateforme Linux (une VM fera l'affaire)

Aucune idée, d'ailleurs les commandes que je me suis compilé sont essentiellement celles qui me faisaient défaut sur le DSM de base (exemple: "lsof", "strace", "inotify*",...), de plus c'est uniquement pour mon architecture (armada370), et enfin ça n'est absolument pas diffusable en l'état (structure un peu rigide et pas vraiment portable).

Comme tu l'as sans doute noté j'ai indiqué que j'ai laissé tomber optware (et ça fait un bail). Ce projet me semble plus vraiment vivant. Je préfère me me compiler avec le SDK les outils dont j'ai besoin. Je ne sais pas de quoi il s'agit

Il y a peu de systèmes permettant de modifier le nom du compte "super administrateur", du moins sans effets de bords. Par exemple, à ma connaissance, renommer "root" sur un unix n'est pas vraiment prévu (je ne connais personne qui le fasse et ça m'étonnerait que ça soit possible sans casse). Egalement, sous Windows, le compte "Administrateur" ("Administrator" sur les version en anglais) n'est simplement pas modifiable. Voila pourquoi je suis étonné du nombre de personnes (car c'est une question récurrente) demandant à faire pareil sur DSM.

Autant que je me souvienne, à l'époque ou je n'avais pas encore abandonné optware, la commande "file" me faisait déjà ça. D’après ce que je vois dans les repositories le package "file" n'a pas eu de mise a jour depuis 2 ans (dans le meilleurs des cas: dernière update datée de 2010 pour certaines architectures). Pas gagné à mon avis.

Sinon il y a la solution du simple reset : https://www.synology.com/fr-fr/knowledgebase/tutorials/493 A part ca et a mon avis c'est pas une bonne idée de ne pas mettre d'expiration des blocages. Dans le cas par exemple d'un un blocage à 24 heures, comment peux-t-on imaginer que quelqu'un qui fait des essais en mode force brute passe le cap en n'ayant droit qu'a deux essais par jour? Autre chose, je conseillerai de mettre en "whitelist" (bouton autoriser/bloquer) l'IP d'un ou plusieurs PC du réseau local pour ne pas se retrouver bloqué comme ici.

Ah oui! comme dirait l'autre ... "c'est du brutal" Mais c'est le résultat qui compte après tout

Solution radicale: le supprimer ("rm /etc/crontab") ou mieux le renommer ("mv /etc/crontab /etc/crontab.bak"). Nous poster une copie pourrait être utile aussi (mais ça peux être juste un pb d'espaces à la place de tabulations, vu que le cron DSM y est très sensible, et un copier/coller risque de masquer ça) redémarrer le NAS (pour faire bon poids) Retourner dans le gestionnaire de tache et faire une modification bidon (changer la minute par exemple) des taches programmées pour s'assuré qu'il soit re-écrit Attention de vérifier aussi les éventuels jobs de sauvegarde programmés.

600Mo c'est encore beaucoup trop si tu veux mon avis, le mien se contente de moins de 10Mb (7380Ln ici): fserv> /bin/ps | grep dms 9691 root 112m S /var/packages/MediaServer/target/sbin/dms 23416 root 4000 S grep dms fserv> grep RSS /proc/9691/status VmRSS: 7380 kB ^^^^^^^

Plus ou mois aussi (mais pas étonnant vu que DSM est made in Taiwan) Blague à part, tu peux encore encore tenter de désinstaller puis réinstaller le package Serveur Multimedia. Et si le problème persiste, je crois que tu coupera pas à une ouverture de ticket au support. Ca peut maintenant se faire directement dans DSM, via le centre de paquets, en cliquant sur "commentaire":

Dans ce cas met directement le code du script dans la fenêtre du planificateur de tache et oublie le script shell. Comme cela: Attention aux retours de ligne dans l'interface, il doit y avoir *exactement* 3 lignes (PATH, [ -t ...] et php) **EDIT** le préfixe "[ -t 0 ] ||" peut même être omis puisque dans ce mode ca c'exécutera toujours en tache de fond: **EDIT#2** Mais qu'il y ait une différence dans le cas d'une exécution avec le bouton "exécuter" et par heure programmée me laisse vraiment perplexe... On dirait que le fichier /etc/crontab a été corrompu **EDIT#3** Bon, la nuit porte conseil comme on dit ... A suivre

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")

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.