CoolRaoul

Pour compléter la réponse de Bud, Ajouter ces deux fonctions dans le script: sub usergroups { my $user = shift; my @groups = scalar getgrgid((getpwnam $user)[3]); # init group list to user main group while (my ($name, $users) = (getgrent)[0, -1]) { $users =~ /b$userb/ and push @groups, $name } return @groups; } sub havegroup { my $user=shift; my $whichgroup=shift; foreach my $groupname (usergroups($user)) { return 1 if $whichgroup eq $groupname; } return undef; } et ensuite remplacer $user ne 'admin' par havegroup($user, 'administrators')

Pour arréter un serveur windows à distance à partir du NAS: /usr/syno/bin/net rpc shutdown -U Administrateur%<mot de passe> -I <ip du serveur windows> Condition: le compte "administrateur" doit être activé sur la machine Windows Pour le faire avec un autre compte qu'administrateur il faut que le compte en question sur la machine Windows ait le privilège "Forcer l'arrêt à partir d'un distance" . Ca se fait par gpedit (sur les versions pro). Une discussion sur le sujet ici: http://forum.hardware.fr/hfr/OSAlternatifs/Divers-2/shutdown-stopper-linux-sujet_64954_1.htm

Si je peux me permettre mon petit grain de sel, je préconise plutôt d'utiliser "/usr/local/etc/rc.d" comme répertoire d'hébergement des scripts de startup "custom" (C'est celui-ci qui est préconisé par Synology pour les scripts "utilisateur") Pour s’exécuter au boot, le script doit simplement être exécutable ("chmod 755" ou, mieux, "chmod a+rx"), son nom est libre mais doit se terminer par ".sh" et il doit accepter les paramétres "start" et "stop" Ce qui nous donne: #!/bin/sh PATH=/bin:/usr/bin case ${1:-start} in start) exec >>/tmp/localmounts.log 2>&1 mount --bind /volume1/photo /volume1/TVIX/PHOTO mount --bind /volume1/music /volume1/TVIX/MUSIC mount --bind /volume1/video /volume1/TVIX/MOVIE ;; stop) for v in PHOTO MUSIC VIDEO do umount /volume1/TVIX/$v done ;; esac en prime, le contenu de "/tmp/localmounts.log" te permettra de visualiser les éventuelles erreurs du script lors de son exécution

Merci pour tous ces témoignages, je fais suivre

Je me permet un petit "UP" sur ma question ci dessus Je viens de faire cadeau à un pote de mon ancien NAS, sans disques. Il me demande conseil savoir quoi acheter. J'avoue ne plus savoir quoi lui répondre

Depuis mon précédent message, j'ai migré mon ds210j vers un ds213j et plus rencontré de problèmes non plus.

Peut-être qu'en fait ce ne sont que les notifications qui sont erronées tandis qu'en fait tout fonctionne correctement. Dans ce cas, le problème devient de suite moins critique. En plus, DDNS est très majoritairement utilisé dans le cadre d'un usage perso (les pro on plutôt des IP fixes) ce qui fait que Synology pourrait considérer ce défaut comme de criticité faible. (tout cela n'étant qu'hypothèses personnelles)

Avec une panne d'un des disques constatée à chaque arrêt, que se passe-t-il dans le cas ou on équipe un simple PC desktop (ayant donc vocation a s'arréter plus souvent) de ces modèles? Ou bien, faut-il conclure qu'un NAS, lors d'un arret, provoque un stress bien plus important qu'un PC sur ses disques. Mais comment l'expliquer?

Inquiétant tout ça .. Et donc, si on cherche la fiabilité maximum (en acceptant des concessions au niveaux des perfs), qu'est ce qui est préconisé? Sont bien gentils chez Hardware FR de nous donner le tableau des modèles ayant les taux de retour les plus élevés, mais il pourraient s'imaginer que ce qui intéresse encore plus les potentiels acheteurs c'est de connaitre ceux qui ont le taux de retour le *moins* élevé, non?

Avec un truc dans ce genre ça ne devrait pas poser de problème à mon avis:

Vu que je l'utilise, je me permet d'ajouter mon petit bémol habituel à cette remarque: le parefeu du NAS, basé sur iptables, permet de mettre des règles bien plus fines que celui d'une box (qui en général n'est tout simplement pas configurable: lorsque un port est redirigé ver le NAS c'est fait sans la moindre restriction). L'utilisation du pare-feu du NAS me permet par exemple de limiter à des IP connues et "amies" les acces autorisés sur certains ports (ssh par exemple) ce que je ne saurais pas faire avec ma box (la question serait peut-être différente avec un routeur suffisamment évolué)

Depuis que j'ai changé mon NAS je ne parviens pas à rétablir les notifications "push" pour DS Finder Aujourd'hui j'ai un nouvelle d'erreur que je n'avais pas les jours derniers En faisant sous DSM: Panneau de configuration -> Notifications -> Service push -> gérer les appareils liés, j'obtiens ceci: Avant d'aller plus loin, est-ce quelqu'un pourrait faire la même manip histoire de savoir si le problème est global ou uniquement de mon coté Merci d'avance

Tu peux aussi (c'est ce que je fais) ne pas faire de raid (pas vraiment utile dans ton cas a moins que la haute disponibilité soit une de tes pre-requis impératifs) et faire des backups du disque 1 sur le disque 2

Avec le blocage d'ip activé tu ne devrais pas trop craindre grand chose Pour le diagramme de flux, ce serait plutôt : Syno_Distant -> Routeur_Distant -> WAN -> Routeur_Local:123456 -> Syno_Local:22 (Les redirections de ports par les routeurs se font uniquement pour les connexions entrantes) Faut commencer à mettre en place la redirection 123456 -> ip_locale_syno:22 sur ton routeur, ça c'est du classique. Et pour le reste, regardes par ici:

Tiens, tu n'a pas rencontré nos problèmes! Par curiosité, quel est ton modèle de NAS? Et quel temps cela a-t-il pris (à relativiser avec la volumétrie, nombre de fichiers scannées essentiellement)

Pas vraiment sur que tu ai bien vu: la rubrique "Achat en boutique" contient *essentiellement* des notification de bon plans:

Informations système -> rapports C'est une fonctionnalité arrivée avec la dernière release de DSM mais le moins que l'on puisse dire c'est que pour le moment ça ne semble pas au point. Les feedbacks reçus montrent que ça tourne des heures voir des jours On en à parlé ici:

Il y a déja une rubrique pour ça: Questions avant achat → Achat en boutique (http://www.nas-forum.com/forum/forum/23-achat-en-boutique/)

Je viens d'effectuer une migration ds210j -> ds213j Depuis lors, sur le ds213j le process "synorcd" (/var/packages/AudioStation/target/sbin/synorcd) consomme en permanence 10% du CPU Je viens d'ouvrir un ticket de support, mais si quelqu'un a une idée je suis preneur...

Je me demandais surtout si la disponibilité de cette toolchain "armada xp" n'était pas une indication de nouveaux modèles à venir non encore annoncés.

Vu qu'il Il y a déja un autre (long) fil sur le sujet: c'était peut-être pas utile d'en ouvrir un autre

Et donc finalement ces toolchains "armada xp" sont destinés à quels modèles?

J'ai pu voir dans la FAQ tormato que dans ce sens c'était supporté en tout cas: Installing from DD-WRT, HyperWRT, etc. firmware Dans l'autre sens je sais pas, faut chercher...

Je ne suis pas sur à 100% pour tormato (quoi que je pense que c'est son cas aussi), mais, en ce qui concerne dd-wrt, il se configure entièrement via l'interface HTTP. Tu trouvera toute la documentation en ligne de ce dernier ici : http://www.dd-wrt.com/wiki/index.php/Main_Page Il existe même un site avec une démo de l'interface d'admin: http://www.dd-wrt.com/demo/ histoire de te faire une idée La config syslog distant est triviale: http://www.dd-wrt.com/demo/Services.asp J'ai l'impression que le support de tormato est moins fourni.

Oh, j'avais cru que tu avais *déja* le routeur Essaie surtout de choisir un modèle supportant le firmware alternatif dd-wrt. Comme ça si in ne gère pas en natif le log distant en syslog, tu aurais toujours la solution de le flasher avec ce firmware alternatif. Un exemple de modèle correspondant à cette spec ici La liste des modèles compatiles dd-wrt : http://www.dd-wrt.com/wiki/index.php/Supported_Devices