Mic13710

Est-ce que les autres applications DS fonctionnent, DS Audio par exemple puisque je vois que vous avez une adresse qui renvoie vers audio.

Il faut supprimer le volume 2 dans le menu Volume, (et peut-être le groupe 2 s'il est toujours présent après la suppression du volume) puis le rajouter au groupe 1 ce qui va créer un shr avec protection des données

Vous confondez deux choses : les capacités du réseau et celles du NAS. Si ce que vous demandez au NAS est trop important au regard de ses performances, il y aura forcément du lag, et ce ne sera pas le réseau mais seulement le NAS qui aura atteint ses limites. Ca n'a rien à voir non plus avec la multiplication des disques et des volumes. Que vous travailliez avec 1 disque pour chaque tâche ou un groupe de disques pour toutes les tâches n'aura pratiquement aucun impact sur les performances. Votre seul soucis est donc de savoir si le NAS que vous avez choisi est suffisamment puissant pour encaisser le travail que vous comptez lui donner.

Vous faite une installation standard en SHR avec protection des données, ce qui est équivalent à un RAID1. Le RAID1 gèree les données à l'identique sur 2 disques. On ne parle pas de copie mais de miroir, les deux disques fonctionnant en parallèle. Mais attention, le RAID ou SHR n'est pas une sauvegarde mais une continuité de service qui permet de continuer à utiliser le NAS en cas de panne d'un des disques. Il suffit alors de remplacer le disque défaillant par un nouveau et de lancer la reconstruction pour retrouver un RAID fonctionnel. Le RAID ne vous dispense pas de faire des sauvegardes de vos données sur un autre support. Pour info, le système est installé sur tous les disques du NAS, pas seulement sur le disque 1. C'est aussi ce qui permet que le NAS continue de fonctionner si un des disques est HS.

Pour moi, il n'y a pas de raison valable de séparer les deux disques, surtout si le deuxième de 8To ne sert qu'à faire du téléchargement. Pas de problème pour la lecture en simultané. Pour info, ce n'est ni le NAS ni les disques qui peuvent dans ce cas impacter sur le débit (le téléchargement est peu gourmand en ressources) mais plutôt le réseau. Donc que ce soit sur un groupe de disques ou deux disques séparés, ce sera blanc bonnet et bonnet blanc. Maintenant, je ne sais pas quels sont les besoins d'infuse Pro, je n'utilise pas ces produits. C'est surtout à ce niveau que les choses peuvent être plus compliquées. Attendre d'autres avis.

Je ne vois rien de particulier, mais comme il n'y a qu'un tout petit élément de ce qu'est le paramétrage du serveur DNS, impossible de dire si c'est bon ou pas. Est-ce que vos adresses publiques fonctionnent correctement côté LAN ? Est-ce que https:\\ndd:5001 renvoie bien sur DSM ?

Si c'est un vrai ndd, le problème est probablement lié à une question de zone. Un ndd qui pointe vers votre P publique ne peut pas se résoudre à partir de votre zone LAN, sauf si le routeur est capable de faire du loopback. La solution c'est de passer par le serveur DNS. Voir le tuto de Fenrir dans la partie tutoriels

Je n'ai pas trop cherché à comprendre votre problème CS/Drive, mais vu les suppressions sauvages, il ne faut pas s'étonner que ça ne fonctionne pas ou mal. Le dossier @cloudstation contient les historiques des fichiers. Comme il est utilisé par CSBackup, vous avez tout simplement détruit sa base de donnée. A votre place, je supprimerais tout les paquets liés à Drive et CS et je les réinstallerais car c'est la seule solution pour redonner du sens à ce qui n'en n'a plus.

Merci de poster des vues de votre gestionnaire de stockage. Si c'est un raid pur (non SHR), il faut étendre manuellement le volume pour pouvoir utiliser la totalité de l'espace. Vous devriez avoir le bouton gérer accessible.

Les ports par défaut de DSFile c'est 7000 et 7001. DSCloud quand à lui utilise le port 6690., mais là n'est pas le propos. Tous les ports utilisés par Synology sont ici : https://www.synology.com/fr-fr/knowledgebase/SRM/tutorial/Service_Application/What_network_ports_are_used_by_SRM_services Si vous voulez ne plus utiliser les ports dédiés pour les applications classiques, il faut passer par le reverse proxy. Vous trouverez d'excellents tutos dans la partie tutoriels. Et si vous voulez utiliser le même ndd côté LAN et côté WAN, il faut mettre en oeuvre le serveur DNS. Là aussi vous avez un excellent tuto sur sa mise en oeuvre dans la partie tutoriels. Je vous conseille d'aller aussi faire un tour en page 2 du même tuto. Vous y trouverez mon retour dans lequel je fais une utilisation du serveur DNS, du reverse proxy et de la mise en place du ou des certificats.

Ok pour la suppression de l'upnp et de la configuration du routeur à partir du NAS, mais avez-vous créé les règles de redirections dans le routeur ? Pour répondre à votre question, pour pouvoir utiliser votre ddns à partir de votre réseau local, il faudrait que votre box soit capable de faire du loopback c'est à dire pouvoir retourner vers le LAN une demande WAN faite à partir du LAN, ce qui n'est probablement pas le cas. Par contre, vous pouvez parfaitement accéder au DSM en local via le https en utilisant l'url https://192.168.x.x:5001. Mais bon, du https lorsque vous faite un lien de chez vous à chez vous, à moins de n'avoir aucune confiance dans les personnes qui utilisent votre réseau, ça n'a guère d'intérêt, surtout qu'il faut alors recourir à des exceptions puisqu'il n'y a pas de certificat couvrant l'IP du NAS. Il faut comprendre qu'un ddns et un nom de domaine ne fonctionnent qu'à partir de l'extérieur. Lorsque vous êtes sur votre réseau privé, ils ne fonctionnent plus puisqu'il n'y a pas d'origine de serveur DNS sur votre propre réseau capable de résoudre ces adresses. Pour que ça fonctionne, il faut donc mettre en place un serveur DNS. Ca tombe bien puisque DSM propose cette fonctionnalité. Il y a un tuto très bien fait sur le forum, mais il faut pour cela que vous ayez un ndd.

Au bout de 4 messages sur ce forum, il serait souhaitable d'aller faire un petit tour dans la section des présentations. Certains y sont sensible. Pour pouvoir répondre à votre question très évasive, il faudrait nous en dire plus sur vos NAS, leur version de DSM, le format des disques (EXT4 ou BTRFS). Quelques vues des deux gestionnaires de stockage seraient les bienvenues.

Oui, c'est normal dans ton cas puisque tu as un wildcard qui renvoie tout sur ton routeur. Si tous les noms sont définis dans ta zone DNS (mon cas), il faut bien une entrée CNAME vers ton ndd ou ns.ndd pour rediriger une requête en www.ndd ou tout autre domaine.ndd En fait, toute requête sur le port 443 qui n'est pas traitée soit par le reverse proxy, soit par le serveur VPN (mon cas) ou tout autre service utilisant ce port est automatiquement dirigée vers le serveur web qui ouvrira le serveur si l'adresse peut être résolu, ou qui renverra une erreur.

si le www n'est pas dans le reverse proxy (où il n'a rien à faire), il ne sera pas résolu par le reverse proxy mais par le serveur web.

Une adresse en www.ndd sera résolue par le serveur web sans passer par le reverse proxy. Mais il ne faut surtout pas mettre une règle pour le www.ndd dans le dit reverse proxy, sinon effectivement il ne saura pas quoi en faire. Il n'y a aucun problème à utiliser le 443 pour quasiment tous les services. Je l'utilise même pour OpenVPN en lieu et place du 1194 pour pouvoir l'utiliser de partout (pas de blocage en entreprise par exemple). Ce n'est encore une fois qu'une question d'adressage. Oui, mais ça c'était avant.

Pour un disque neuf, c'est énorme.

Si le disque est neuf, il faudrait commencer par lui faire passer les batteries de test constructeur pour confirmer que le disque à un problème. Pour moi, un disque qui présente au démarrage ne serait-ce qu'un seul secteur défectueux, c'est retour direct.

Moi non plus, je ne vois pas l'intérêt de translater le 443. Le but du reverse proxy c'est bien d'orienter les requêtes vers les applications. Les services web ne sont pas altérés si le 443 est utilisé par le reverse proxy. Ce n'est qu'une question de paramétrage. En plus, l'idée du reverse proxy c'est aussi de pouvoir utiliser la même adresse sur le LAN et sur le WAN. Si on fait une translation 443 WAN vers 6443 LAN, il faut alors modifier l'url selon qu'on se connecte à partir du WAN ou du LAN. Je laisse imaginer la complication. Désolé, je suis peut-être vieux (et probablement vieux jeu), mais sur ce forum c'est comme dans la vie, je ne tutoie que les familiers. Je devrais peut-être moi aussi l'indiquer dans ma signature 😉

Comme tu dis, c'est plus ou moins la même chose. La notation du nom de domaine dans les enregistrements est un peu déroutante puisque au lieu d'utiliser le ndd en clair, on utilise l'@. Il n'y a pas de service ddns chez Gandi, mais c'est sans importance puisque chez free, l'ip est en principe fixe.

Vous confondez 2 choses, le parefeu du NAS qui filtre les accès au NAS et les règles de routage qui elles concernent le routeur (votre BOX). Comme il est dit dans le tuto, on doit autoriser le 1701 dans le parefeu du NAS mais on ne le transfère pas au niveau du routeur. Or, avec les règles que vous avez mis en place dans la configuration du routeur (qui n'a rien à voir avec le parefeu, on est bien d'accord), vous faite très exactement le contraire puisque vous indiquez au routeur de rediriger le 1701 vers le NAS. Il faut supprimer de votre liste la règle pour le 1701. Au delà de ce problème, il n'est pas recommandé de laisser le NAS gérer les ouvertures et redirections des ports du routeur. C'est très clairement expliqué dans le tuto sur la sécurisation de nos NAS. Tout ce qui concerne les réglages du routeur doit exclusivement être fait au niveau du routeur. On ne laisse pas le soin à des équipements tiers (le NAS dans le cas présent), faire de paramétrages sans contrôle. Je vous recommande de désactiver la configuration du routeur du NAS, de désactiver par la même occasion l'Upnp du routeur pour bloquer les tentatives de réglages externes et de faire vos translations et redirections de ports directement dans l'interface du routeur. C'est plus propre, plus sécuritaire, et c'est vous qui en gardez le contrôle. Le port 5001 sert à se connecter au DSM pour principalement y faire des paramétrages. Sauf cas particuliers, il n'est généralement pas nécessaire ni conseillé de le faire à distance. Ce type d'action est plutôt réalisé en local pour d'abord pouvoir intervenir en cas de problème, et ensuite, bien que la liaison soit en https, elle n'est pas garantie sécurisée à 100%. Si vous utilisez le VPN pour rejoindre votre réseau local et qu'il est bien entendu fonctionnel, vous n'avez pas besoin d'ouvrir le 5001 vers l'extérieur. Moins il y a de ports ouverts, mieux c'est.

C''est justement le rôle du reverse proxy de pouvoir diriger vers chaque application sans avoir à passer par DSM. Si on veut uniquement accéder à video station, pourquoi passer par DSM pour lancer le paquet alors qu'il est infiniment plus simple de déclarer un ndd du genre video.ndd pour ouvrir directement video station. Ceci dit, vous êtes tout à fait en droit de faire compliqué alors qu'une solution simple existe. A vous de voir où se situe la simplicité d'usage ! 😊

Les liens de partage se créent simplement à partir de file station. Mais pour que ces liens puissent fonctionner il faut : que le NAS soit accessible de l'extérieur, que la connexion au NAS au moment de la création du lien soit dans le même protocole que celui dans lequel le lien devra fonctionner (généralement du https). C'est un dysfonctionnement de DSM qui crée les liens en http ou en https selon que la connexion est elle même en http ou en https, (ceci étant dit, on peut toujours corriger le lien, mais le QRcode ne correspond plus) que les paramètres de connexion et de ports qui ont été renseignés dans les accès externe, onglet avancées soient corrects car ce sont eux qui seront utilisés par DSM pour créer le lien.

Bonjour thony2324, soyez le bienvenu dans la communauté

Bonjour jeje33, soyez le bienvenu dans la communauté

Bonjour joselyon69, soyez le bienvenu dans la communauté. Il y a effectivement quelque chose d'urgent à faire. Posez votre question dans le forum dédié.