CoolRaoul

C'est tres surprenant Voici ce que ca donne pour moi: uid=0(root) gid=0(root) euid=1032(clampin) egid=100(users) groups=100(users),65540(localusers),65541(people),65553(photo_r) Vu que tu utilises bash, peut-être qu'il intègre une commande "id" en builtin avec un comportement différent. Essaie de forcer la commade "id" externe (en mettant explicitement le path complet: /usr/bin/id) Autre piste (me semble plus probable): j'ai mis ma commande "id" directement dans le champ "script défini par l'utilisateur" de déclaration de tache. Fort possible que l'appel d'un script externe (et donc un sous-shell) fasse perdre le contexte suid.

Les scripts définis par le planificateur de tache pour un autre utilisateur que "root" sont exécutés en mode suid/sgid (je viens de le découvrir moi aussi) Tu n'a pas fait gaffe mais dans le résultat de ta commande "id", alors que uid vaut bien "root", la présence de "euid" correspondant au compte utilisateur effectif (et egid pour le groupe principal) Un petit test me montre en outre que la variable HOME n'est pas présente dans l'environnement du job Peut être que l'erreur vient en partie de là. Tu peux essayer d'indiquer explicitement le chemin de ta clé privé en argument de la commande ssh (ssh -i <chemin de la clé) Mais surtout, je préconise de mettre en début de ton script un truc du genre de: if [ "$HOME" = "" ] ; then HOME=~<mettre_le_user_ici> export HOME fi Car l'absence de HOME ne peut que provoquer d'autre effets biens velus à débugger.

M'enfin! Le lien vers cette liste à été donné trois messages plus tôt! (

On avance, voila déja qui prouve que DS audio fonctionne bien sur les deux lans. Et avec l'IP externe? Sinon tu n'as pas répondu à ma 2ème question du message message précédent, à savoir: Sachant qu'il y a plusieurs façons différentes de se connecter à audiostation (connexion DSM puis activation audiostation dans le menu, en direct via un port ou un chemin dédié) il serait utile que tu testes chacune d'elles.

Bien que le webdav Hubic sot mort et enterré, BOX est toujours opérationnel. Et la manip décrite ici dans ce tuto fonctionne toujours (je l'utilise) Faut juste noter que l'url webdav box à changé, c'est maintenant "https://dav.box.com/dav" comme documenté ici.

Essaie d'aller voir quel profil a été attribué au téléviseur et à la PS43 dans "serveur multimedia", onglet "compatibilité DMA" puis "liste des périphériques" La PS3 dispose d'un profil spécifique ("Playstation3") Tu peux tenter de de voir ce que ça donne avec l'un ou l'autre des "Default Profile ..." .

Plutot que de reposter une deuxième fois sur le même problème faudrait peut-être commencer par répondre au questions posées dans le fil précédent

De chez toi si tu utilise l'ip locale du NAS sur le lan 1 pour se connecter à audiostation dans ton navigateur ça marche ou pas? Si ça ne marche pas quelle est l'erreur? Ca aiderait aussi de donner plus de détails: est-ce que tu te connecte via un chemin et/ou des ports spécifiques pour audiostation que tu aurais définis dans panneau de conf -> portail des application?

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?