CoolRaoul

Il aurait fallu commencer par nous montrer les logs mettant ce phénomène en évidence plutôt que la log précédente qui ne montre que les cas ou ça fonctionne comme prévu Mais, vu que ton service SSH, bien qu'inactivé dans le panneau de conf apparaît toujours actif , serait pas étonnant qu'il soit dans un état un peu ... brumeux. Commence par relancer la NAS pour que déja tout se remette d"équerre et ensuite on verra.

Tu a bien écris, je cite, "sauf qu'il arrive à déjouer le blocage"? Arriver à déjouer le blocage, si il ne s'agit pas d'une connexion réussie, de quoi s'agit-il alors? **edit** Si si le service n'est pas coché alors qu'on constate qu'il crache des logs c'est franchement zarbi Je te conseille de redémarrer ton NAS puis de tester une connexion ssh en local, juste pour voir

Ce log montre que, contrairement à ce que tu penses, ton service SSH *est* actif Et en outre, si tu as des traces de connexions reussies (non bloquées donc) c'est tout betement qu'elle viennent d'une autre IP qu'une de celles qui ont été bloquées et que le gugusse a trouvé le mot de passe.

Et si tu nous montrais un extrait de ces logs? Si, comme tu le dis, le port ssh n'est pas ouvert (aur passage peux-tu donner plus de détails par ce que tu veux dire par la ?) , je ne vois pas comment on peut constater une connexion ssh dans quelque log que ce soit

Tu as bien écrit que le port SSH n'était "pas ouvert pour le moment" ? Par conséquent, le blocage d'IP ne joue aucune rôle dans ce cas sur le port SSH et, en outre, je ne comprend pas sur quoi tu te bases pour dire que le blocage d'IP avait été contourné .

Pas vraiment ce qui est demandé: DS Download tourne sur Androïd. Son navigateur n'est pas intégré dans l'interface DSM web.

Un DS213 à 219€: 2 http://www.topachat.com/pages/detail2_cat_est_reseau_puis_rubrique_est_w_nas_puis_ref_est_in10063497.html

"Le disque dur à l'hélium d'Hitachi risque de révolutionner le marché" une économie d'énergie pouvant grimper jusqu'à 23% par rapport à des disques durs traditionnels. chauffent moins (4 à 5° de moins) et sont moins bruyants. La suite ici

Ou bien qu'il y ait un lézard quelque part du genre un câble foireux. Quand, dans de gros transferts entre un des PC et le NAS, le second PC en vient carrément à ne plus pouvoir transférer faut déjà commencer par vérifier l'ensemble des équipements. Peut-être déjà commencer par relever les compteurs d'erreurs CRC au niveau des différentes interfaces ethernet.

Pour le dire autrement, je ne parviens tout simplement pas à imaginer, dans le cadre d'une utilisation domestique, quel pourrait être le type d'usage requérant suffisamment *souvent et simultanément* des transfert entre deux PC et un NAS jusqu'a percevoir une bande passante d'un gigabit comme insuffisante. Par contre je comprend tout à fait ce besoin dans le cadre d'une utilisation "pro", avec par exemple des dizaines de postes clients reliés à un NAS unique. Et encore, faudrait-il qu'ils effectuent des transferts plus ou moins au même moment ce qui est rarement le cas. On ne doit pas avoir la même définition du mot "fréquent" : je peux te garantir que mettre en oeuvre *à domicile* une archi de ce genre est loin d'être la norme. Je ne serai d'ailleurs pas étonné que l'écrasante majorité des gens utilisant un NAS dans un cadre privé ne sachent même pas en quoi ça consiste.

Merci de l'avoir confirmé (n'ayant pas de machine Linux avec double environnement desktop installé sous la main pour tester j'ai du rester à l'étape des suppositions). Donc, dans ce cas, vu le fonctionnel n'est pas impacté, faut pas trop espérer que le support Synology considère cela comme un bug prioritaire, étant donné qu'il ne s'agit que d'un aspect "cosmétique".

Et sinon, pour le patch proposé, je ne suis pas sur ça pose vraiment un problème d'utiliser gnome-terminal comme émulateur terminal pour faire tourner le script d'install même dans le contexte d'une session KDE. A partir du moment ou la commande "gnome-terminal" est disponible dans le PATH (ce que la commande "type gnome-terminal" détermine) la script d'install devrait se dérouler normalement.

C'est essentiellement l'absence même du mot "cloudstation" dans le sujet (contrairement a la phrase ci dessus) qui a fait je n'ai pas compris de quoi il s'agissait. M'étonnerait pas que d'autres soit autant perdus que moi. Voila pourquoi j'ai proposé l'option proposée de poster dans le bon sous-forum. Il est aussi possible de modifier le sujet du post. Mais c'est toi qui vois ...

Oui parce que la ça vient un peu comme un cheveu sur la soupe je trouve. Et en postant plutôt dans http://www.nas-forum.com/forum/forum/199-cloud-station/ ça aurait clarifié le contexte

Erreur de forum?

Non c'est bien du DLNA: (on peut d'ailleurs facilement imaginer que s'il utilisait un protocole différent, le téléviseur Samsung aurait du mal à le comprendre)

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: