Mic13710

D'où mon conseil : Pour vos problèmes de débit, c'est au niveau du réseau qu'il faut regarder. Mais comme je ne connais pas votre installation, je ne peux pas trop vous aider. Le Wifi est très souvent la cause d'une perte de débit. Tout dépend de la force du signal, de la qualité de la borne, des interférences, du type de transmission (a, b, n, ac) et de beaucoup d'autres facteurs.

Elle peut être installée manuellement. Il suffit de télécharger le fichier .pat correspondant à votre NAS (dont on ne connait pas le modèle soit dit en passant) sur le site Syno.

C'est sûr que le serveur DNS demande un gros effort pour sa mise en oeuvre. J'ai assez galéré sur le mien. Mais quand ça fonctionne, c'est vraiment le top. Ceci étant dit, on s'éloigne très fortement du sujet initial. Aussi, je vous conseille d'ouvrir un autre sujet pour traiter de vos autres questions auxquelles je répondrais bien volontiers si je peux.

Merci pour ce retour.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

C'est tout à fait normal. Le nas reçoit une requête mais ne sait pas à qui elle est adressée. Vous pouvez par exemple paramétrer des alias dans le portail des applications, mais je vous conseille plutôt de vous tourner du côté du serveur dns (un autre excellent tuto de Fenrir) et du reverse proxy.

Il n'y avait aucune intention de classer ni de vexer qui que ce soit. Ce que j'ai écrit est la stricte vérité. J'ai déjà vu au moins 2 cas depuis que je suis sur ce forum. On ne sait pas à priori à qui on a affaire, ni son niveau de compétence. Raison pour laquelle je préfère que le disque soit retiré pour éviter tout simplement que ça se reproduise . On a tous été des débutants un jour. Et oui, comme vous le faite remarquer, le wifi c'est lent. Il ne faut surtout pas utiliser ce mode de connexion sur un NAS. Le filaire et rien que le filaire. Si ce n'est pas possible, à la rigueur des CPL, mais surtout pas le wifi.

Il y a une nouvelle version sortie aujourd'hui : 6.1.1-15101

Soit pas pressé, actuellement ils sont en plein débugage .

Apparemment il y est maintenant sur presque tous les modèles, ainsi que le .pat.

Les dates de maj dépendent de ce qui est programmé dans le cron. 5 jours c'est ok. T'imagines la pagaille si tous les NAS faisaient leur maj en même temps ? Perso j'attends encore quelques temps avant de basculer à la 6.1. Je viens tout juste de passer à la 6.0. Pas trop de nouveautés à la fois.

Je n'ai pas la 6.1 mais j'ai eu aujourd'hui tout un stock de maj des paquets dont beaucoup concernaient la 6.1.1 J'ai eu quelques messages surprenants sur les paquets multimédia, photo station et surveillance station comme quoi l'installation avait échoué, mais au final, tout a l'air de fonctionner. Un bug ?

¨Pour tout te dire, j'ai fait une demande au support hier pour savoir comment on pouvait choisir. C'était avant que je comprenne que c'était le mode de connexion qui dictait le type du lien, mais ça reste toujours d'actualité. Voici mon message : Bonjour, A moins que quelque chose m'ait échappé, je ne comprends pas pourquoi il est impossible de choisir le type de connexion (http ou https) pour les liens partagés. J'ai activé le serveur DNS dans lequel j'ai un nom de domaine spécifique pour les fichiers : file.mondomaine.fr. Pour simplifier, mes accès externes se font sur le port https par défaut : 443. Dans "Accès externe", onglet "Avancé" j'ai indiqué le nom d'hôte file.mondomaine.fr, le port 80 pour le HTTP et le 443 pour le HTTPS. Or quand je crée un lien sur un fichier, celui-ci est sous la forme http:\\file.mondomaine.fr:80\sharing\etc.. D'accord, je peux modifier l'adresse à la main pour la passer en https, mais ce n'est pas une solution acceptable et surtout je ne peux rien faire pour le QCode. Pourtant dans les paramètres de File Station il y a bien le choix d'un lien en HTTPS, mais il ne concerne que QuickConnect! Pourquoi n'est-il pas possible de faire de même avec un lien classique ? A quoi bon indiquer dans "Accès externe" les ports http et https utilisés si l'utilisateur ne peut pas choisir celui qui doit être pris en compte pour la création des liens partagés ? J’avoue ne pas bien comprendre. Comme je l’ai dit, il est possible que j’aie raté quelque chose, aussi, pouvez-vous me dire comment faire ce choix ? D’avance merci pour votre aide. J'attends leur réponse.

Je vais jouer à Macron. Je suis d'accord avec toi. C'est vrai que la proposition "par défaut" devrait être en https, à condition toutefois d'avoir un certificat valide (ce qui n'est pas le cas de tout le monde). En même temps, on peut très bien avoir besoin du http pour des partages en réseau privé ou bien pour des fichiers lourds et/ou non critiques (vidéos, photos par exemple) pour lesquels le https va impacter inutilement le temps de téléchargement. Je vois plusieurs possibilités : Soit du https "par défaut" Soit comme pour QC, la possibilité de choisir dans les paramètres de filestation (ou ailleurs peu importe) le type de lien qu'on souhaite avoir pour les partages Soit créer les deux avec la possibilité de choisir celui qui est à conserver dans la liste des liens partagés Soit une combinaison des trois : par défaut en https, choix permanent http ou https, choix à la carte Il est clair de toute manière qu'il y a matière à amélioration. C'est tout de même aberrant que ce soit le NAS qui décide du type de lien alors qu'il ne connait pas le besoin.

J'ai déjà vu ça par le passé. Certains ont fait plusieurs tours de pistes avant de comprendre. L'expérience mon cher, l'expérience...

C'est surtout pour éviter que l'installation reparte sur un nouveau SHR. Avec un seul disque, pas de risque. Mais si ça peut se faire sans, tant mieux.

C'est tout à fait possible de migrer de l'un vers l'autre, mais vous aurez probablement quelques réglages à reprendre. Voir la base de connaissances sur la migration pour la marche à suivre. Un point important : il ne faudrait pas que vos disques soient issus d'une migration précédente sinon vous risquez de très vite être confronté à des limitations.

Absolument d'accord. Et je m'étonne que Synology n'ait encore rien fait à ce sujet alors que cette fonction de lien partagé existe depuis quelques années (DSM4.1 si je ne m'abuse).

Le reverse proxy intégré depuis DSM6.0 dans le portail des applications est en effet suffisant pour les besoins courants. Perso je n'utilise que celui-là.

Il faut aller fouiller le forum des Tutorials. Vous y trouverez l'excellent tuto de Fenrir sur la sécurisation du NAS (il est épinglé en tête de forum) et beaucoup d'autres tutos.

La raison du pourquoi oui, la solution non. Le problème est toujours là.

Effectivement, je viens de tester sur mon portable avec un fichier CloudStation où le lien avec le serveur CS est en https. Le lien de partage créé est bien en https. Le même test sur mon PC fixe où le lien avec le serveur CS est en http me crée un lien en http. Une belle con....rie. S'agissant d'un lien qui par nature peut être appelé à partir du LAN (moins courant) ou du WAN (beaucoup plus fréquent), la logique voudrait qu'on puisse choisir comment il doit être structuré. Ce ne devrait en tout cas pas être le mode de connexion en cours à décider si le lien est en http ou en https. Et puisque ce choix est possible si on utilise QC, il devrait l'être de la même manière pour un lien classique. Sincèrement, je ne comprends pas du tout la logique.

Oui. Mais je ne vois pas en quoi ça aurait une influence dans la mesure où c'est un lien externe qu'on crée. Si c'était ça, ce serait stupide de la part de Synology car les accès sont différents suivant qu'on est sur le LAN ou sur le WAN.

Excepté les soucis du départ, ça semble tourner pour moi aussi. Je vais tenter d'en mettre un peu plus à l'occasion histoire de charger la mule et aussi de faire une restauration pour voir si ça fonctionne dans l'autre sens.

C'est tout de même incompréhensible. J'ai beau chercher dans les paramètres et je ne vois rien qui cloche. Je dois passer à côté d'un truc simplissime, mais quoi...