CoolRaoul

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.

En outre le 215j est particulièrement peu gourmand en énergie (encore mieux que le DS213j dont c'était déjà le point fort)

L'éventualité de la disponibilité de DSVideo sur d'autre TVs que les Samsung est une question posée depuis un bout bout de temps sur le forum officiel: http://forum.synology.com/enu/viewtopic.php?f=219&t=79941&start=15 Toujours rien n'a été annoncé. NB: les Sony Bravia disposent bien d'un store qui se nomme "Sony Entertainment Network", on y trouve par exemple Netflix, Pluzz et plein d'autre choses mais pas DSVideo donc. **EDIT** Mais bien entendu, ta TV Sony pourra aussi accéder aux Video du NAS en utilisant le protocole DLNA, et si tu as intégré VideoStation au serveur multimedia tu retrouvera directement la même organisation pour la navigation arborescente dans les medias.

Puisqu'on disgresse sur le choix d'emplacement: je conseille d'éviter ceux sujets à de fortes variation de températures sur des périodes courtes (c'est bien moins la valeur absolue de la température que sa vitesse de variation qui est critique). Y a pas mieux pour faire souffrir les équipements électroniques (qui plus est ceux comportant des pièces mobiles comme les disques durs ici).

Bigre! Débuter en NAS avec un 1815+, tu ne fais pas les choses à moitié. Enfin, bref ce n'est pas le sujet. DSM permet de programmer démarrage et arrêt automatiquement. Il va de soi que cela aura pour résultat que chacun des disques va subir 2X365 cycles par an, ce qui ne peut qu'être nuisible à sa fiabilité à la longue, comme tout équipement de ce type. Note bien que c'est déjà mieux que l'hibernation qui peut avoir pour conséquence, suivant l'usage, plusieurs cycles *par jour*. En résumé on n'a rien sans rien: dans les modèles haute performance comme celui-ci, qu'on trouve plus souvent en entreprise que dans une chambre, Synology ne privilégie pas bien entendu la réduction des nuisances sonores. Reste donc à toi de peser le pour et le contre, bruit/confort VS fiabilité

Le 2eme nom que tu vois apparaître via la freebox est celui déclaré dans les métadonnées du .mp4. Il est possible d'aller éditer ces infos avec un outil d'édition de métadonnées (mais je ne connais pas pour les mp4) Sinon, autre approche, demander au serveur multimedia du NAS de toujours diffuser le nom du fichier en décochant la case comme ci dessous:

Un truc que j'ai oublié (surtout que je n'avais pas percuté que c'est le *renommage* dont tu voulais te protéger): dans le modèle de droits Unix qui est ici utilisé (lecture/écriture/exécution pour "propriétaire"/"groupe"/"autres"), la possibilité de supprimer et renommer des fichiers ne dépend pas des droits sur les *fichiers* mais des droits sur le *répertoire* qui les contient: c'est le droit d'écriture sur le dossier qui permet les opérations de renommage ou d'effacement. Les droits d'écriture sur les fichiers eux-mêmes permettent de modifier le *contenu* du fichier (en fait c'est parfois un peu plus compliqué que ça: alors qu'on crois modifier un fichier "A", l'application utilisée peut tres choisir d'utiliser une version temporaire du fichier (disons "A.tmp") et terminer l'opération par un renommage et alors on se retrouve dans le cas précédent. Pour gérer plus finement les droits, faudrait passer ton dossier partagé du NAS en modèle de sécurité basé sur les ACL (comme sous windows), mais c'est bien plus complexe à maîtriser. Le mieux est alors de commencer par se créér un dossier partagé de test, histoire de s’entraîner a ces manipulations.

Et voila ton explication!

La methode utilisant haproxy necessite de disposer d'une box (ou modem routeur) sachant faire de la redirection en changeant le numéro de port (exemple port externe -> port 5580 sur le NAS). Les BOX de certains FAI (en suisse si je me souviens bien) ne savent pas faire.

Ne plus avoir d'IP fixe n'est pas un problème: il suffit de configurer un DYNDNS (par exemple le service fourni par Synology) et au lieu d'utiliser l'IP pour se connecter de l'extérieur à ton NAS, faudra passer par son nom DNS à la place (an ayant redirigé le port dans la box bien entendu)

Peux-tu nous détailler comment tu t'y es pris pour "'mettre les fichiers en lecture seule dans l'interface web"? Par filestation, "propriétés" -> "permissions" je suppose? Quels droits as-tu mis? (un screenshot pourrait être utile) A noter aussi que si tu utilise le comte "admin" (ou tout compte du groupe DSM des administrateurs) pour la connexion samba au NAS, ça bypasse les droits.

Pas possible: le pare-feu n'a aucune visibilité des comptes utilisateurs. Il filtre à partir des IP sources externes à destination de services (ports) interne, c'est a peu prés tout.

Faudrait peut-être juste recadrer la fonction de la shoutbox, par exemple avec un petit "disclaimer" dans le bandeau (mais est-ce possible?):

http://www.synology.fr se contente de faire une redirection sur https://www.synology.com/fr-fr/. En attendant utiliser la 2eme url

C'est la "5.1-5004 Update 2" sortie *aujourd’hui* qui a supprimé le resize du profile.

En effet la dernière update a supprimé la commande "resize" de "/etc/profile" que j'ai signalé un peu plus tot qui était la source du problème

Et sinon ça peut aussi se faire en ligne de commande: /usr/syno/bin/synoconfbkp export --filepath=<fichier> --option=all Remplacer <fichier> par un chemin de fichier non existant (mieux à mettre dans un script qui calcule par exemple son nom en fonction de la date)