CoolRaoul

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)

Non seulement elle est toujours la mais elle est même non désactivable: (suis en 5.1 également)

L'update à été retirée a cause de faux positifs dans le centre de sécurité. Ca a été confirmé par un post d'un officiel Syno sur le forum officiel: "we have noticed this false alarm issue and working on the fix. the next update should fix this problem and will be available shortly."

Depuis longtemps je me suis aperçu que synoaudiod (/var/packages/AudioStation/target/sbin/synoaudiod) consomme du CPU en permanence. Ce matin j'ai voulu en avoir le coeur net et décidé d'investiguer plus avant A l'aide de la commande "truss", cross compilée avec le SDK, j'ai pu observer ce comportement select(1024, [3], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({1417247511, 826053}, NULL) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) gettimeofday({1417247511, 829573}, NULL) = 0 open("/tmp/AudioStation/player.list.json", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40091000 write(8, "{"last_update":1417247511,"uuid:"..., 582) = 582 close( = 0 munmap(0x40091000, 4096) = 0 open("/dev/mixer7", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer6", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer5", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer4", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer3", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer2", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/dev/mixer", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) nanosleep({0, 100000000}, NULL) = 0 et ca continue en boucle. Le plus étrange sont ces ouvertures/ecriture/fermeture frénétiques (10 fois par seconde!) dans "/tmp/AudioStation/player.list.json" Qui saurait me dire à quoi sert ce process et quels sont les conséquences de l'inhiber? J'aurais bien ouvert un ticket de support chez Syno, mais hélas j'ai un point de montage "/opt", et même si ce n'est pas du optware, sous ce prétexte, on me refuse toute aide tant que je n'ai pas effectué un reset usine de mon NAS.

Peut-être un espoir avec la toute nouvelle update DSM 5.1? https://www.synology.com/fr-fr/releaseNote/DS213j "Fixed an issue where cgi cannot be executed in Web Station"

A mon avis la piste est a creuser du coté de l'erreur "#!/usr/bin/perl: not found".

Gaffe: ici le cgi s'exécute sous le compte "root" et pas "http" car le "su - http" retourne immédiatement à la session initiale (sous réserve que le shell du compte ait été laissé à sa valeur par défaut, "/bin/false"): fserv> su - http fserv> id uid=0(root) gid=0(root) groups=0(root) Faut ajouter "-s /bin/sh" à la commande "su" pour éviter ça.

Normalement, ça devrait aussi marcher sans le "perl", sous réserve que le script soit exécutable (et c'est le cas d’après les résultats de tes "ls") et que la ligne shebang soit correcte Cependant l'erreur: /var/services/web/test.cgi: line 1: #!/usr/bin/perl: not found semble indiquer le contraire Es-tu sur que le .cgi à bien été créé avec Notepad++ configuré (préférences->nouveau document->format des sauts de lignes) pour utiliser les fins de lignes unix? Pour corriger: "édition" -> "convertir les sauts de lignes"

Ah non, au temps pour moi, la bonne commande est su - http -s /bin/sh -c "perl /var/services/web/test.cgi" (mais pourquoi avoir répondu auparavant "Donc dans SSH celà fonctionne avec cette ligne de commande" ?)

Faut plutôt faire ce test avec les droits du compte http, en s'y prenant comme cela: su - http -s /bin/sh -c "perl /var/services/web/cgi-bin/test.cgi"