CoolRaoul

Donc ce n'est pas un probleme du au NAS CQFD

http://www.synology.com/support/faq_show.php?q_id=127&lang=fre

Est-ce que l'un de tes deux lecteurs BD n'aurait pas un port USB par hasard? Si oui, copies un des films qui ne passent pas sur une clé USB, et essaie de le lire à partir de la clé avec le lecteur BD. Si ça plante de la même manière, on saura que ce n'est pas le NAS qui est en cause

Je m'étais un peu emmelé les pinceaux sur ce dossier, et il est bon de reclarifier. Faut bien distinguer les "dossiers partagés" (ce que le support nomme "top-level folder"), et les dossiers "normaux" contenus dans ces derniers, quelque soit le niveau de profondeur. Les premiers sont en effet par défaut visibles dans l'explorateur, en ouvrant la branche du voisinage réseau correspondant au NAS, ou en tapant directement le chemin UNC "<nom_du_nas>. L'option "Masquer les dossiers et les fichiers des utilisateurs sans autorisations" ne s'applique bien qu'aux autres. Reste quand même une possibilité pour masquer certains partages: il est possible de le faire pour *tous* les utilisateurs. Ceux qui y on effectivement accès pourront toujours y accéder en tapant le nom UNC (<serveur><partage>) ou en mappant une lettre de lecteur, les autres n'y verront que du feu. C'est pas parfait mais mieux que rien. L'option est celle-ci:

Proxy Web sur le NAS Reverse Proxy via l'apache du NAS haproxy tunneling des ports et 443 via une connexion SSH ***EDIT*** Sans oublier la solution toute simple d'ouvrir des ports supplémentaire dans le routeur, chacun redirigés vers les ports d'admin http des différents équipements respectifs.

Et le message d'erreur est ... ? **EDIT** PS: le MAC n'a pas accès directement au dossier du NAS, obligé de passer par file station? Ah moins que le MAC et le NAS ne soient pas sur le même site (on manque de détails pour bien comprendre la situation)

Je ne comprend pas quel est le problème: tu reçois (de tes clients des fichiers dont le nom contient des underscores, le NAS les affiche avec ces underscores. Il n'y a apparemment aucune anomalie (ou alors c'est qu'il est nécessaire de détailler plus précisément quelle est l'erreur). Pas parvenu à trouver dans l'interface DSM l'endroit ou ce trouve cette commande "partage de fichier -> Charger", si tu pouvais nous en dire plus. Quant à l'"echec cause "underscore" il se manifeste *comment* exactement (quel est le message d'erreur *exact*) ?

Sont quand même parfois un peu excessifs au niveau de leur politique de diffusion de patchs chez Syno (me souviens pas d'avoir vu de patch diffusé publiquement d'ailleurs) Par exemple j'ai récupéré "par la bande" (sans monter un dossier au support donc) le patch qui résout les problèmes d'enregistrement des fichiers Microsoft Office sur les partages avec ACL activé. M'étonnerait fort qu'il ne s'applique pas à tout le monde (et il résout effectivement le bug).

Vérifier que c'est bien le mode passif qu'utilise filezilla ***edit*** (normalement c'est le défaurt pour filezilla mais on sait jamais)

J'espère que le contact du support qui va m'être assigné ne va pas me sortir que c'est la cause d'optware comme ça m'est déja arrivé:

Bon, c'est fait, j'espère avoir été assez clair dans les explications que j'ai donné.

En résumé, après avoir fait la matrice complète de tests possible: La connexion webdav fonctionne dans *toutes* les configuration en WIFI sur le réseau local. En data, ne marche que la connexion utilisant le reverse proxy (port ou port 443 en SSL). A noter que je me suis trompé a plusieurs reprises en croyant à une reussite alors que c'était une erreur de mode opérationnel. Sur le NAS de mon collègue j'ai le meme comportement que sur le mien finalement. Lorsque j'ai cru que DS File remarchait apres un reboot c'est parce que j'avais fait mon 1er test via mon reverse proxy. C'est quand meme incompréhensible que ce soit la connexion utilisant le mode "naturel" du syno (connexion directe sur ports 5005 en non crypté et port 5006 en SSL) qui soit défaillante alors qu'en passant par le reverse proxy (qui n'est pas une methode officielement et explicitement supportée) J'ouvrirai bien un dossier chez Syno sur ce problème, m'a c'est tellement tordu que je suis découragé rien que d'imaginer comment aller leur expliquer tout ça.

Finalement pas tout a fait: je peux me en effet connecter en https webdav via dsfile en utilisant via mon reverse proxy (port 443 et le sous-domaine que j'ai configuré pour le webdav), par contre, en https direct (port 5006, que ce soit explicite ou implicite) ça ne marche qu'en WIFI pas en data. (symptomes identique et remplacant https par http). Ca me gonfle tout ça. (heureusement que j'ai du temps libre pour quelque jours)

Commence par rebooter PC et Syno, histoire de repartir sur une base saine et dis nous ce qu'il en est. PS: tu n'a pas installé de firewall sur ton PC en complément de celui de Windows? Le firewall du Syno est il activé et si oui laisse-t-il bien passer le protocole dlna?

Est installé mais je ne lui laisse pas toutes libertés: les plugins navigateurs sont désactivé par exemple. Aucun process java en tache de fond non plus. Ensuite, java n'est pas nécessaire pour l'intégralité des composant du SDK Androïd, la partie adb and co tourne sans lui il me semble (sous réserve de vérification). je gardé la capture tcpdump déjà, mais ça risque de ne pas être suffisant.

N'est pas tout a fait intact mon tel: le bootloader est déverrouillé quand même. Mais jusqu'ici toutes les bidouilles velues que j'ai eu a y faire n'ont pas nécessité de le "rooter". Par exemple, pour modifier des fichiers dans la partition système je le boote via adb sur une image "unsecure", je remonte la partition en r/w et je fais les manips en ligne de commande via le shell ADB. Ça m'a suffit jusqu'ici (je pense que ça devrait être assez geek pour toi ) Desinstall/reinstall de DSFile (sans reboot) m'a débloqué la situation Va comprendre! Dingue ça!

Suis pas rooté, mais j'avais effacé le cache DSfile avec le gestionnaire d'applis android. Je ne comprend pas comment ça peut se comporter différemment en connexion wifi et en data (pb de MTU ?) , j'ai bien essayé de faire une trace avec tcpdump pour l'analyser avec wireshark mais çà dépasse mes compétences. Vais essayer de desinstaller/installer DSfile.

Suite de mes investigations: Je parviens a me connecter sur le NAS d'un pote avec mon DSFile (Wifi *et* data) Donc le problème est du coté de mon Syno.

Trouvé une autre solution alternative, mon navigateur de fichier de prédilection sous Androïd (ES Explorer) supporte le webdav et je l'ignorais (faut dire que ça se cache dans l'onglet "FTP" ) Et, inutile de le dire, avec lui, ça fonctionne aussi! Mais quel peut bien être le problème avec DSFile alors?

Encore un des bugs de la 4.2 Il y a un fil qui en parle sur le forum US: http://forum.synology.com/enu/viewtopic.php?f=19&t=55977&start=30 Seule solution trouvée (pour l'instant): rebooter

Bon, suite de mes tests: A la maison connexion en wifi (sur mon réseau local donc) OK (c'est quand même le minimum). Par contre, une fois wifi désactivé et data activée sur le téléphone, même erreur "la connexion à échoué etc... " qui apparaît après la phase d'authentification (qui réussi elle). Pour aller plus avant, j'ai testé un client webdav sur le téléphone (le module webdav de Total Commander) et avec celui-la, la connexion réussit! (bon ça me fait une solution alternative, c'est déjà ça) Je n'y comprend plus rien de rien maintenant.

Cela semble indiquer que le serveur multimedia du syno n'est pas démarré Vérifie si tu as bien cet icone dans le menu principal DSM: Sauf erreur de ma part ce n'est que depuis hier que tu nous as soumis ton problème, avec jusqu'ici une seule réponse. Ca me semble un peu précipité pour désespérer

Tu penses bien que j'ai retapé le mot de passe (c'est pas aux vieux singes qu'on va apprendre à faire la grimace) , suis même allé jusqu'à vider le cache et les données de l'appli DSfile (ce qui vide tout son historique y compris les mdp enregistrés)

C'est quand même un peu chelou: maintenant, si je met volontairement un mot de passe faux ça échoue avec le message "compte ou mot de passe incorrect", par contre avec le bon mot de passe la connexion semble se faire puis finalement me dit: "la connexion à échoué, veuillez vous reconnecter et ressayer" Le fait que le comportement soit *différent* avec le bon mot de passe ou pas prouve que la connexion est établie entre DSFile et le NAS (pour échanger user et passe), alors comment expliquer ce qui se passe? Je ferai des tests ce soir de chez moi en wifi et en data pour voir.

Bon, je crois que c'est ma connexion data qui est naze (fait dire que la ou je suis c'est pas le pérou), DS Audio me dit "réseau pas disponible" lui Faudra que j'essaye d'ailleurs Me suis laissé abuser par le message d'erreur qui n'indique certainement pas la vrai cause de l'échec