CoolRaoul

Faudrait commencer par essayer en interne en utilisant successivement les deux IP locales pour cerner un peu mieux le problème.

Non, pas des masses. Serait-il possible de nous décrire la la manip effectuée (en commençant juste avant "impossible de l'ouvrir"), pas à pas si possible et quel est le message d'erreur? PS: quand tu parle de file station, on est bien d'accord: il s'agit bien du composant DSM qui se lance par l'icone ci dessous?

D'apres la liste de sports (http://www.synology.com/fr-fr/support/faq/299), à moins d'utiliser airplay, tout le traffic audiostation passe via les ports http "systeme" (5000, et 5001 en ssl par défaut) et le serveur http ouvre sa socket d'écoute en mode "INADDR_ANY" (*) que je sache. Que constates-tu exactement pour en arriver à ta conclusion?

Tu as trouvé quelque chose? Parce que de mon coté je ne reçois toujours rien.

Est-ce systématique ou seulement dans le cas d'un répertoire bien identifié? Car sinon, sans connaitre le contenu du répertoire en question tu dois bien imaginer qu'on va avoir du mal a diagnostiquer. Sinon, s'agit-il d'une url http ou ftp?

Faudrait décrire plus en détail (pas à pas si possible) les manips effectuées (en essayant simplement de se mettre à la place de quelqu'un qui tente de reproduire le problème) Par exemple "ouvrir le fichier config.in" n'est pas tres clair: est ce que tu fait simplement un double clic sur le fichier ou choisis une action du menu contextuel? De même "j'essaye de passer en 777 mais j'y arrive pas.": comment t'y est-tu pris pour essayer de changer les permissions? A priori tu as du passer par le menu "propriété" et essayé de modifier ici: Quel a été le message d'erreur en cliquant sur "OK"?

Toute la manip est normalement expliquée ici: http://www.synology.com/fr-fr/support/tutorials/485

Pourquoi ces modifs ? (d'autant plus que les 2 premières options sont celles par défaut de sshd) Ca dépend,tu ne nous as pas expliqué ce que tu voulais faire en connection ssh déja.

Si en connexion filaire il n'y a pas de problème il est clair que le problème n'est pas coté NAS déja. Tenir comte aussi que les débits wifi sont des débits théoriques Essaie de déplacer provisoirement le PC juste à coté de la box. Si le débit redevient correct c'est qu'il y a des obstacles et/ou trop de distance entre l'ordi et la box. Sinon pour voir si le problème est coté box ou coté PC, essayer avec un autre PC pour comparer.

En ssh c'est le compte "root" qu'il faut utiliser a la place d'admin (aucun autre compte n'est autorisé en ssh par défaut: le champ shell dans /etc/passwd est "nologin") "admin" n'est un compte privilégié uniquement quand utilisé pour se connecter via l'interface Http DSM. En login terminal shell, c'est un compte comme les autres. Si besoin est, faut savoir que DSM synchronise le mot de passe "root" avec le mot de passe "admin" En outre, je ne pense pas que les modifications de config sshd soit nécessaires (et surtout le "PasswordAuthentication no" est risqué si tu perd ta clé, mais tu auras l'option d'activer telnet provisoirement en secours cependant).

Être concis n'est pas forcément la voie la plus efficace pour trouver de l'aide. Copie effectuée de quelle manière ? Quel message d'erreur ?

Ah je vois, une grande famille avec des problèmes de communication apparemment (non je déconne) Bon, dans le pire des cas, la situation ce que tu décris va engendrer un trafic crête de quelques dizaines de megabits/seconde. Bien en deçà de la bande passante d'un lien gigabit unique. Juste le gus qui édite les photos pourra peut-être gagner quelques pouillèmes quand il fera fichier->enregistrer et fichier->ouvrir (et même ça j'y crois pas trop). En même si ça valait la peine faut se demander avec quelle fréquence ce type d'utilisation de ton réseau va se produire: je ne pense pas que le jeu en vaille la chandelle. Sans la moindre hésitation je peux te garantir que tu ne constaterais la moindre amélioration mesurable et encore moins perceptible en mettant en place cette architecture. A ta place je mettrai de coté mon argent (parce qu'il va falloir investir dans un swith "pro") pour l'utiliser de façon plus efficace et/ou en se faisant plaisir. Mais bon, c'est toi qui vois. Il y a eu récemment une longue discussion sur le sujet dans le forum, essaie de la retrouver tu y trouvera des infos utiles.

Tous les dossiers dont le nom commence par "@" sont des dossiers systèmes qui sont normalement exclus de toute visibilité sur le réseau. Il est peut être possible de les faire apparaître en SMB temporairement en bidouillant à la main le fichier smb.conf mais la modif sera écrasée a la moindre modif ultérieure de paramètres de dossiers partagée et de toute façon c'est fortement déconseillé. Autre approche: je me rappelle avoir conseillé un jour une astuce à quelqu'un qui voulait faire modifier juste un dossier situé sous @appstore (et ça avait marché) Ca consistait à déplacer le dossier en question quelque part dans un dossier partagé et remplacer le dossier d'origine par un lien symbolique vers le nouvel emplacement. Suffisait alors de modifier les fichiers par réseau via le nouvel emplacement. **EDIT** J'ai retrouvé mon post: tu peux t'inspirer de cette approche je pense

Avant toute chose demande toi bien si tu as besoin. Dans le cadre d'une utilisation personnelle, même avec beaucoup d'équipements, ça ne peut avoir d'utilité uniquement quand un grand nombre d'entre eux effectuent *simultanément* des transfert à plein débit avec le NAS. Le cas type ou l'agrégation de lien peut être efficace est un NAS en entreprise sur lequel sont connectés de tres nombreux postes ou serveurs clients actifs simultanément. M'étonnerait que tu te retrouve souvent dans ce type de situation. Inversement, dans le cas d'un seul flux réseau à un instant T (1 seul appareil <-> NAS, typique d'une utilisation a domicile), pour doubler le flux faudrait que l'appareil lui aussi dispose de deux ports ethernet et supporte l’agrégation de liens. Faut savoir aussi que visualiser un film (même en HD) en streaming va n'occuper qu'une toute petit pourcentage du débit maximum gigabit.

Ne reste donc plus qu'a remettre la planification telle qu'elle était initialement et attendre que ça replante. Car il serait étonnant qu'avoir ajouté le logging au script ait miraculeusement réparé le problème.

Si j'ai bien compris ce qui c'est passé, un de tes disque du mirroir a laché. Le RAID est toujours opérationnel mais sur une seule "patte". Ce qui fait que le volume reste accessible sous DSM est il reste possible de le sauvegarder sur un support externe. Il ne s'agit que d'un backup par sécurité: si tu dispose déjà de sauvegardes (ce que as peut-être mis en place si tu a lu les ), tu peux bien évidemment t'abstenir de cette étape. Ensuite, lors du redémarrage après remplacement du disque en panne le RAID va passer en phase de reconstruction. PS: par curiosité: pourquoi avoir choisi de mettre en oeuvre un RAID sur ton NAS, est-ce que tu as des contraintes de haute disponibilité (limiter le "downtime" au maximum) ou tu n'a pas envisagé les solutions alternatives?

Et bien j'ai l'impression qu'on a atteint les limites de ce qu'on peut faire à distance en terme de diagnostic. Et tout cas moi je sèche Juste une dernière question, le dernière erreur ("Configuring ipkg-opt.ipk...WARNING: can't open config file: /usr/syno/ssl/openssl.cnf"), quelle est la commande qui l'a provoquée?

Faire exactement ce que j'ai décrit dans mon post un peu plus haut: mettre les lignes que j'ai données "en début de script" (dans boot.sh en l'occurence, juste au dessus de la ligne "#Déclaration des variables" par exemple )

Non: à partir du moment ou l'autre script est inviqué par la commande ".", il s'exécute dans le contexte de l’appelant. (c'est grosso modo équivalent à une commande "include" présente dans d'autres langages) J'ai bon espoir que le contenu du fichier log nous donnera l'explication. Tiens nous au courant du résultat

Juste savoir que le droit "exécuter" est un pre-requis pour avoir acces a tout ce qui est en dessous (on peut le voir comme le droit de *traverser* dans le cas d'un dossier) . Le doit "lecture" sur un dossier ne permet que de voir la liste des *noms* des objets (dossiers et ou fichiers) contenus par ce dernier. Tout dépend ce que tu veux faire exactement. Il est probable que des que tu va vouloir mettre en place une matrice de droits d’accès (utilisateurs X groupes X dossiers) plus complexe tu atteignes les limites du modèle basé sur [propriétaire, groupe, autres]. La solution serait alors d'activer les ACL sur le dossier partagé. Mais attention c'est plus compliqué. J'ai participé récemment à un fil sur le sujet, je pense que sa lecture pourra t’intéresser C'est ici:

Alors commencer par mettre le logging en place comme j'ai indiqué déjà pour y voir plus clair. NB: mettre des fichiers perso dans la hiérarchie "/usr/syno" est casse-gueule car ils seront irrémédiablement supprimés lors de toute mise à jour DSM (mais à priori pas dans le cas de simple correctifs). Il est bien plus approprié de choisir l'arborescence "/usr/local" qui est toujours préservée (c'est documenté).

Non, la ça indique juste que le PATH est toujours incorrect Que donne "echo $PATH" ?

On ne pouvait pas deviner Il est important de bien comprendre la différence entre ne pas voir la *présence* d'un dossier et ne pas avoir *acces* à un dossier (en lire le contenu): Quand l'utilisateur *voit* un dossier cela signifie qu'il a un droit de lecture au dossier qui le contient. Les droits du dossier lui-même ne sont pas pertinents dans ce cas. Avoir *acces* à un dossier nécessite que l'on ait au moins les droits d'exécution (et lecture en plus dans le cas de filestation) à tous les dossiers de niveau supérieur jusqu’à la racine (le dossier partagé) et au moins droit de lecture au dossier lui-même. Par suite, la seule façon vraiment efficace pour cacher la présence d'un dossier est de le situer dans un autre dossier auquel l'utilisateur n'a pas accès en lecture. Prendre l'analogie avec une armoire fermée a clé (pas d'acces) mais dont la porte est transparente (droit de lecture: on voit les dossiers qu'elle contient mais le contenu de ces derniers) NB: ce n'est pas tout a fait exact sous DSM car il existe une option pour cacher automatiquement les éléments auquel on n'a pas accès mais me semble avoir lu qu'elle ne s'applique pas très bien à tous les modes de partage réseau

Tu as pourtant écrit *exactement* le contraire: "En fait si je copie mes dossiers et sous dossiers dans un autre répertoire que photo tout fonctionne mais je ne sais pas pourquoi..." Tout dépend des droits des dossiers, je ne vois rien d'étonnant là. Les droits de ces différents dossiers (ou d'un de leur dossiers parents) doivent être différents. Faut les vérifier. Pas trop moi non plus j'avoue, ça manque peut-être de détail et de plus c'est pas facile à suivre.

Maintenant que ça devient plus spécifique, pour haproxy, faudrait plutôt poster dans cette section: http://www.nas-forum.com/forum/forum/210-paquets-fournis-par-synocommunitycom/