CoolRaoul

Je me disais que certains membres du forum avaient des contacts direct chez le staff syno, surtout si il peut y avoir un problème de sécurité.

On trouve pourtant ici-même, dans le forum, des témoignages semblant indiquer que dans certaines configurations ce soit supporté. Exemple: (mais je reconnais ne pas avoir testé)

... qu'un htacces commence par "." ? http://usdl.synology.com/download/DiskStation/DSM4.3/3805/

Ma réponse était destinée uniquement à te faire ré-évaluer tes besoins afin peut-être de reconsidérer la nécessité d'une telle architecture. Dans le cadre d'une utilisation domestique (il me semble comprendre que c'est le cas) ça me semble franchement surdimensionné. Un autre point a aussi prendre en compte, c'est qu'en mettant en oeuvre une configuration moins répandue, fatalement, en cas de problèmes, tu trouvera moins de personnes disposant ce type d'archi capable de t'aider en reproduisant les anomalies. Cela dit, il y a des membres du forum utilisent des Synology dans un environnement pro. Je suis sur que certains d'entre eux seront plus qualifiés que moi pour répondre de façon plus précise et ne devraient pas tarder à intervenir sur le fil.

Suis pas sur de bien percuter l'intérêt de mettre en oeuvre l'aggrégation de lien dans cette config (d'autant plus qu'un seul des équipements du réseau le supporte). Dans le cadre de la topologie citée en exemple, on se demande quelle configuration de flux réseau serait capable de consommer plus d'un gigabit de débit en sortie et/ou en entrée du NAS.

Dans ce cas, ce fil devrait te donner des idées de boitiers qui répondraient à ton besoin:

Pour augmenter tes chances (si tu ne l'as pas déjà fait), tu devrais en parallèle chercher de l'aide sur un forum Apple. Sans oublier de mettre à jour ce fil si tu trouve des pistes.

Peut-être que tout simplement le client SMB MacOsX n'est pas compatible avec cette option? Tu as tenté le coup au hasard ou tu es sur de toi? (NB: je n'ai pas de compétences MacOS)

Avant toute chose, essayer d'appliquer l'astuce que j'ai signalée:

Il y a un long fil sur le sujet: Tu devrais essayer de le parcourir et de t'y accrocher

En effet: plus précisément, à chaque connexion, les règles sont examinées dans l'ordre de haut vers le bas. Des que la partie "condition" d'une règle s'applique, l'action (accepter ou refuser) est appliquée et les règles suivantes ne sont pas traitées.

Faut créer deux règles. La première: a.b.c.d étant l'IP distante à autoriser Suivi d'une autre identique mais avec "IP Source=<tous>" et action="refuser" Bien s'assurer que la seconde règle soit située apres la première (en dessous dans la liste) La 2eme règle est inutile si on a choisi l'approche ci dessous: (mais dans ce cas ne pas oublier d'avoir prévu inclus une règle autorisant le réseau local sous peine de devoir faire un reset de la conf firewall via le bouton magique)

Personne n'a proposé ça

Comme j'ai écris: "d'autres pourront peut-être donner plus de détails.." patience donc Je me souviens que ça a été discuté ici même dans le forum, mais je ne trouve pas les bins mot-clés à utilisér pour retrouver les fils sur le sujet.

Ah ... le navigateur dans le navigateur. Ca faisait longtemps que le sujet n'était pas revenu sur la table... Pour faire court, la réponse est non. Mais d'autres pourront peut-être donner plus de détails..

La voix du bon sens. Les plus fortunés peuvent même envisager l'investissement d'une tablette (se connectant à internet en tethering via son smartphone) pour plus de confort.

En effet et c'est d'ailleurs pourquoi je n'avais pas remarqué jusqu'ici qu'elle était apparue avec la 4.3.

Pourquoi me parles-tu de la commande "halt" ? **EDIT** plus précisément, vu que la commande "shutdown" existe sous DSM 4.3, oublie "halt" et pour arrêter le NAS, la bonne façon de procéder est: shutdown -h now Et si tu veux éviter tout risque d’arrêt partiel due à la déconnexion intempestive de la console (je crois que shutdown sait gérer ça mais ça ne mange pas de main), alors utilise : nohup shutdown -h now Note: "-h" pour un arret (halt) et "-r" pour un reboot.

Auparavant, sous DSM la seule commande dispo pour rédémarrer était reboot" Et pour avoir la garantie que la commande ne soit pas interrompue par une coupure de connexion, fallait faire: nohup reboot Mais en effet je découvre que "shutdown" est disponible désormais: fserv> /sbin/shutdown --help Usage: shutdown [OPTION]... TIME [MESSAGE] Bring the system down. Options: -r reboot after shutdown -h halt or power off after shutdown -H halt after shutdown (implies -h) -P power off after shutdown (implies -h) -c cancel a running shutdown -k only send warnings, don t shutdown -q, --quiet reduce output to errors only -v, --verbose increase output to include informational messages --help display this help and exit --version output version information and exit TIME may have different formats, the most common is simply the word 'now' which will bring the system down immediately. Other valid formats are +m, where m is the number of minutes to wait until shutting down and hh:mm which specifies the time on the 24hr clock. Donc je confirme que "shutdown -r" comme préconisé est la bonne méthode (et le préfixer par nohup ne fait pas de mal de toutes façon)

Suffit de réfléchir 5 mn: les 50mbits d'upload sur la fibre représentent à peine 5% de la bande passante ethernet théorique du NAS *sans* le link agrégation. A quoi bond augmenter la taille du robinet quand le tuyau est 20 fois plus petit? Sans oublier que c'est *toute* la chaîne *de bout en bout* entre le NAS et le poste client à l'autre bout qui devrait supporter également le doublement de bande passante. Pas besoin d'aller plus loin donc. PS: stp, essaie de ne pas le prendre directement pour toi, mais j'ai l'impression que beaucoup insistent à mettre en place une infrastructure link aggrégation dans le cadre d'une utilisation domestique juste pour jouer à qui à la plus grosse.

Et voila que maintenant le firmware est en ligne: http://usdl.synology.com/download/DiskStation/DSM4.3/3803/

Question déjà posée (et toujours pas de solution):

Pour ma part je n'utilise pas le serveur de mail et je suis très content de cette nouvelle version niveau conso CPU. Voir ici: Et sinon je préfère largement cette nouvelle politique de "hotfixes" comparé à l'approche antérieure ou, lorsque un problème avéré était corrigé, en attendant la version complète suivante, chacun devait *individuellement* ouvrir un dossier au support pour bénéficier d'un lien de téléchargement (tout en reconnaissant que la confidentialité de ces liens était toute relative puisqu'il fuitaient assez rapidement sur les forums, mais c'est plus sain maintenant je trouve).

Depuis cette dernière update tout est redevenu normal pour moi niveau CPU. Et comme rien ne remplace une image:

On dirait que ça revient, j'ai reçu 4 notifications sur sujets suivis depuis ce matin. C'est réparé?