CoolRaoul

Faudrait commencer par ouvrir un fil dédié, parce qu'ici dans "Support des logiciels Synology -> Accès à vos données" je pas certain que ce soit le meilleur endroit Choisir par exemple: Divers -> Underground / Modifications ou Divers -> Newbie du monde Linux Ensuite faudra se poser la question du *pourquoi* installer Optware", projet à l'abandon depuis des années (voir ce que j'en pense ici)

Vu que ma demande de restauration (suite à mon post mentionné ci dessus) ne s'est pas concrétisée, à ta place je me garderai de trop d'optimisme.

Suite à une fausse manip, m'est arrivé la même chose sur un tuto, qui plus est très fourni de questions/réponses. Pas eu de retour sur une possible restauration: http://www.nas-forum.com/forum/topic/51395-jai-fais-une-cie/ J'en ai déduis que le forum ne dispose apparemment pas de sauvegardes. Faut donc faire très attention ! (extrême coup de pot j'avais précisément sauvegardé le contenu brut du post initial une semaine plus tot, par contre toutes les commentaires associés ont irrémédiablement disparu)

Sinon (c'est pas forcément le même usage mais ça convient dans mon cas) Le client Keepass windows officiel ainsi que celui que j'utilise sous android (Keepass2Android) savent tous deux accéder en lecture/écriture a la base de mots de passe en Webdav et/ou sftp.

Sans doute, mais en tout cas, je pense que ça devrait rester optionnel, et en tout cas explicitement documenté dans les releases notes (je ne demande qu'a être contredit si je me trompe mais je n'ai pas remarqué)

Salut à tous, Je viens de m'apercevoir que (depuis quand, je n'ai pas cherché) l'historique des commandes shell tapées en mode terminal sont loggées dans syslog Plus particulièremet le résultat d'un simple: grep HISTORY /var/log/messages est édifiant Qui aurait une idée de l'intérêt (et de la pertinence) de la chose et par quelle magie c'est activé?

Il y a deux méthodes pour accéder à distance à un NAS. Simplifiée, via quickconnect, ou en direct. C'est expliqué ici: Comment rendre le NAS de Synology accessible sur Internet Quickconnect est la méthode simplifiée (avec quelques restrictons). L'accs via l'url "quickConnect.to" devrait fonctionner sous réserve que le service auquel tu cherche à te connecter (tu nous as pas dit lequel) soit coché dans Panneau de configuration -> "QuickConnect" -> "avancés" Sinon reste la méthode directe qui nécessite de rediriger des ports dans ton routeur. Comme EZ-internet ne s'applique dans ton cas, va falloir appliquer les instructions "Configurer manuellement votre routeur" dans l'aide dont j'ai donné le lien plus haut. Je ne connais spécifiquement ton modèle de routeur mais je t'ai retrouvé la page de documentation applicable à cette situation ici: Configuration de port range forwarding (redirection de la plage de port) sur le Routeur Wi-Fi Linksys ou la passerelle Tiens nous au courant.

Un poil plus compliqué que la mienne, donnée juste avant! on dépose le script, correctement nommé et chmodé, directement dans le "/usr/local/etc/rc.d/" et roule ma poule. En plus je ne suis pas sur que cette méthode, qui ajoute un fichier dans "/etc/init" résiste au upgrades DSM (alors que le contenu de /usr/local est garanti conservé par Synology dans ces circonstances)

Les options "tache déclenchée sur événement (démarrer/éteindre) n'est apparue qu'avec DSM6 Pour les version précédentes faut mettre les mains dans le cambouis (plus exactement dans "/usr/local/etc/rc.d") et suivre ces instructions: If you would like to run an application when the system boots up, you have to write a startup script and put it in /usr/local/etc/rc.d/. Following are some rules for the startup script: 1. It must have the suffix “.sh”. For example, “myprog.sh”. 2. The permission must be 755. 3. It must have the options “start” and “stop”. When the system boots up, it will call “myprog.sh start”; when it shuts down, it will call “myprog.sh stop”. You can refer to the scripts in /usr/syno/etc/rc.d/. They are script for Synology default services.

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