CoolRaoul

Ah oui en effet, je n'étais pas allé assez loin. Ca risque d'être problématique alors. Mais pour quelle raison vouloir utiliser ce language sur un NAS? Un PC ne serait-il pas plus approprié? En effet, on peu lire sur la page Install OCaml que c'est supporté sur un grand nombre de plate-formes. Pourquoi choisir justement une parmi celles non validées? D'autant plus qu'en cas de dysfonctionnement ca pourrait s'avérer sportif de trouver quelqu'un utilisant la même plate-forme pour obtenir de l'aide.

Pas sur qu'Optware soit nécessaire d’après ce que je lis sur cette page: "How to install opam" Ca à eu l'air de marcher pour moi (suis pas allé plus loin que "opam --help" mais a priori ca semble bootstrappé) NB: non seulement le projet Optware est en hibernation, plus supporté depuis des lustres mais quand il est installé sur un Syno toute ouverture de ticket au support reste bloquée tant que c'est le cas. Mieux vaut éviter de l'utiliser quand c'est possible.

Au cas ou tu ne l'aurais pas remarqué, tu cites un post qui date de 3 ans (06/2013) et dont le dernier signe de vie de l'auteur (ref) sur le forum remonte à près de 2 ans de ça (08/2014) J'espère que tu ne met pas trop d'espoir sur l'arrivée d'une réponse rapide

C'est vrai que les permissions ça peut rapidement devenir un peu "touchy" si on ne respecte pas quelques règles de base: quand on a à gérer un plusieurs utilisateurs partageant une typologie commune, *systématiquement* commencer par créer un groupe correspondant. Par exemple ici nommé "clients", à créer dans la section "groupes" du panneau de configuration DSM. Ca permettra de gérer des droits de façon globale là ou c'est approprié. ne *jamais* utiliser les permissions de type "refuser". En général il est toujours plus simple de n'autoriser que ceux qui sont habilités, les autres se voyant étant automatiquement refusé tout accès. Ici ça va donc donner: Création du groupe "clients", lui donner le droit FTP dans l'onglet "applications". Création du dossier partagé, nous l'appellerons "clients". Pour ses permissions, sélectionner le mode "groupe locaux", et positionner lecture/écriture pour le groupe "clients" (on va affiner ça ensuite dans FileStation) Création de comptes DSM : client1, client2, etc. chacun d'eux appartenant ua groupe "clients" et rien de plus au niveau des droits. Dans file station maintenant sélectionner le partage "clients" Propriétés -> permissions -> "clients" -> décocher tout sauf "Traverser les dossiers/Exécuter les fichiers" Y créer un sous dossier par client. Pour chacun d'entre eux: Propriétés options avancées -> "exclure les permissions héritées" "Créer" Champ "utilisateur ou groupe" -> <nom du compte client> Zone "permission" : tout cocher dans lire et écrire, rien ailleurs. Résultat de la manip (si je n'ai rien oublié): les clients pourront se connecter en ftp, verront le partage "clients" mais n'auront pas le droit d'en lister le contenu. Ils devront aller directement dans le dossier qui leur est attribué (commande ftp "cd clients/<nom_clients>", à configurer dans leur application ftp ou par un raccourci sur leur poste de travail) Dans ce dossier ils auront tous les droits, et rien en dehors (ca peut s'affiner ensuite si nécessaire) Ce qui empêche les clients de lister le contenu du dossier des autres clients est le fait d'avoir décoché le droit "lister les dossier" du dossier partagé "clients". Si on fait partie du groupe client on peut le traverser mais il faut savoir le nom du sous-dossier où on veut atterrir. Il n'est hélas pas possible, en ftp en tout cas, de rendre un dossier invisible à certains utilisateurs (l'option "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" ne s'applique pas en mode ftp hélas)

Même plus besoin de script, en parcourant le forum Syno US je viens de tomber sur ce post qui mentionne la commande "synonet", native à partir de DSM6. Usage: synonet --wake [MAC address] eth0

Et vu qu'on est dans l'univers Mac, il n'est peut-être pas inutile de rappeler qu'un Syno peut faire office de serveur "Time Machine":

Plus simple, si on veut strictement répondre à la requête exprimée dans le titre du fil, il y a ça: OK, je sors, pas pu m’empêcher Mais avant de sortir: Tu ne dis pas de bêtise: ça consiste à utiliser une partie dédiée (LUNs SCSI) de l'espace de stockage NAS comme bibliothèque de contenu VmWare (disques virtuels, ISOs) mutualisée, pour les VM d'un ou de plusieurs serveurs VmWare. Autant dire qu'on parle là d'environnement "pro" et que la bande passante réseau a intérêt à assurer (LAN 10GB de bout en bout recommandé) et c'est pas par hasard que c'est réservé aux modèles Syno "High End"

3.2.40 (DSM 6.0.1-7393 sur DS213j)

Devrait marcher aussi bien que celui dont j'ai donné le lien Et tu peux faire abstraction de ton niveau en programation puisqu'il suffit de le recopier tel quel pour l'utiliser. Pas besoin de comprendre son fonctionnement.

Beaucoup plus simple à mon avis: Installer (si ce n'est déja fait) le package "perl" pour DSM. télécharger ce script: http://rom-o-matic.net/gpxe/gpxe-0.9.3/contrib/wakeonlan/wakeup.pl le déposer dans un répertoire de son choix du NAS programmer l'appel du script via le planificateur de tâches intégré à DSM avec la commande ci dessous: perl <chemin du script>/wakeup.pl <addresse mac de l'équipement à réveiller>

Encore une erreur de ma part, manque un "+" c'est $(date "+%F")

Ah oui, en effet, j'avais oublié: faut créer le répertoire au préalable, Suffit d'ajouter cette ligne au dessus de la commande "mv": mkdir -p /volume1/commun/archive/archive-$(date %F)/ Ou mieux, utiliser des variables, comme ceci: srcdir=/volume1/commun/incoming dstdir=/volume1/commun/archive/archive-$(date %F) mkdir -p $dstdir mv --backup=numbered $srcdir/* $dstdir/ Pas forcément une bonne idée, une erreur de frappe est vite arrivée avec des résultats potentiellement à problème Le gestionnaire de taches de DSM permet de choisir sous quel compte utilisateur effectuer la tache, mieux vaut utiliser cette option.

En effet, mais reconnaissons que ce problème était déjà implicitement présent dans la solution initiale C'est peut-être plutôt sur le contrôle du traffic qu'il faudra jouer plutôt (dans "panneau de conf" -> "réseau" ) Mais je dois avouer n'avoir pas encore expérimenté cette fonction.

Ah j'avoue ne pas avoir trop investigué les modes de restriction d’accès de VideoStation, faut expérimenter. En tout cas ne pas oublier que si le paquet "serveur multimedia" est actif ce dernier donne acces sur le réseau local à tous les fichiers videos situés dans des dossiers indexés (ce qui s'ajuste dans "panneau de configuration" -> "service d'indexation" -> "dossiers indexés"). En effet le protocole DLNA qui est utilisé dans ce cas n'implémente pas d'authentification.

Suffit de descendre d'un cran le contenu du partage documentaires dans un sous dossier et le tour est joué (peut-être pas très élégant en local, mais transparent pour les utilisateurs distants) Autre possibilité, déplacer ce dossier "Documentaires" comme sous dossier du partage "Video".

Réfection de la facade est (le coté ouest ayant été fait il y a quelques années de ça) Et je peux te dire que la douloureuse est salée pour les propriétaires

Peut être suffit-il dans le gestionnaire de stockage de supprimer les LUN SCSI pour pouvoir créer des volumes locaux En tout cas ca vaut le coup d'essayer **EDIT** J'ai voulu vérifier si il état possible de simuler ça sur la démo DSM en ligne mais je ne trouve aucune indication du compte et du mot de passe à utiliser!

Pour ce que tu veux faire, me semble qu'il vaut mieux d'utiliser la fonction "partage de liens de fichiers" de filestation, appliqué à un dossier. Ca aura pour effet de générer un lien qui donne acces uniquement à ce dossier, en lecture seule, soit de façon anonyme soit avec authentification Dans filestation sélectionner le dossier, puis "partager les liens de fichier"

Comme quoi il n'y a pas de règle. Je tenais à donner un exemple que NAS-Forum n'est pas le seul dans ce cas et la réponse ne peut pas être simplement de se dire "pas de chance, pourquoi sommes-nous les seuls à être attaqués?". Il existe des méthodes a la fois préventives et réactives comme cela à été abordé dans ce fil, il est impératif d'en mettre en oeuvre au plus vite. (pour ma part le captcha à chaque post ca me gonflerait grave, mais si on ne peux faire mieux faudra vivre avec) Je ne pense pas. je dirai plutôt que déléguer, même partiellement, c'est aussi accorder sa confiance et ca c'est jamais facile de but en blanc.

Tu n'avais parlé que de fichiers pas de dossiers. La solution est celle-ci: find /volume1/commun/incoming -maxdepth 1 ! -name 'nepassauvergarder' | xargs --no-run-if-empty mv -t /volume1/commun/archive Note: on peut ajouter en argument de "find" d'autres "! -name <fichier ou dossier à exclure>" et pour ces derniers utiliser des jokers ("*", "*", etc ...) avec un "find | xargs" en entrée on inverse le sens du "mv": "mv -t <destination> <fichier_ou_dossier> ... Ca c'est simple: mv --backup=numbered /volume1/commun/incoming/* /volume1/commun/archive-$(date %F)/ (Il existe d'autre formats possible pour la date) Références doc de "find": http://linux.die.net/man/1/find doc de "date": http://linux.die.net/man/1/date doc de "xargs": http://linux.die.net/man/1/xargs Nb: si tu as d'autres questions sur les commandes en ligne je t'engage à poursuivre dans une des section "Newbie du monde Linux" ou"Terminal Telnet et SSH"

En fait c'est simplement plus visible du fait que le nettoyage n'est pas fait assez vite. Je suis responsable de section sur un autre forum francophone (FrAndroid pour ne pas le nommer) est là-bas aussi il arrive fréquemment de subir ce des flots de spams exactement du même type et tout autant volumineux. La différence est que, grâce justement à l'existence d'une équipe modération suffisamment importante, le flot est très rapidement endigué et la plupart des visiteurs n'ont pas le temps de s'en apercevoir.

suffit de faire une tache quotidienne programmée via le planificateur de taches intégré à DSM avec la commande suivante: mv --backup=numbered <chemin dossier_source>/* <chemin dossier_destination> ("--backup" sert à ne pas écraser les fichiers du même nom comme demandé) Exemple: mv --backup=numbered /volume1/commun/incoming/* /volume1/commun/archive/ Documentation commande "mv" ici: https://www.gnu.org/software/coreutils/manual/html_node/mv-invocation.html

Quelle est la question exactement? Pour les acces fichiers, la Freebox ne supporte (en externe) que FTPES, FileStation ne le supporte pas. je ne vois pas trop quoi ajouter.

C'est pas en insultant les gens que tu feras avancer le dossier Résumons: le besoin est simplement que le Mac accede à internet en ethernet plutôt qu'en WIFI. La solution qu'on propose est quasiment la norme en terme de bonnes pratiques: (internet) | | [ BOX/routeur ] | | | | | +--- <autres équipements, en direct ou via un switch> [NAS] [PC/Mac] L'investissement se résume à l'achat d'un malheureux cable ethernet (qu'on doit trouver pour à peu prix le prix de deux paquets de café moulu). Pourquoi chercher à tout prix une solution alternative plus complexe ? La méthode que tu cherches consisterait à configurer le NAS en mode "routeur". Via une recherche rapide suis tombé sur ce fil daté de plus de deux ans sur le sujet qui décrit une méthode pour éventuellement y parvenir: https://forum.synology.com/enu/viewtopic.php?t=70083 Mais d'une part je ne suis pas sur que ca fonctionne à l'identique sur la dernière version de DSM, de l'autre c'est bien entendu non supporté et probablement mis en oeuvre quasiment par personne. Par suite, en cas de problème de fonctionnement, faut pas compter trouver facilement de l'aide ni de la part de Synology, ni des utilisateurs (qui ne sauront pas reproduire ton setup pour pouvoir analyser)

Ah tiens, j'ignorais ça: j'étais persuadé que le serveur multimedia qui assure la fonction DLNA savait tirer partie du décodage à la volée des modèles "play" lui aussi.