Toutes les discussions

Quelles sont les références de vos disques, ceux installés et le nouveau ? La techno des disques a son importance.

Merci de ton interet à mon message. Je viens de faire la mise à jour du DSM en 7.3.2-86009 Update3 . Le probléme persiste même message d' échec . Cela peut-il provenir d'un formatage defectueux en amont . je l'ai realise dans un lecteur R-volution et j'ai trouvé cela trés rapide( lecteur de fichier de film pour le homecinema qui possede un onglet formatage) Peut être je peux recommencer en utilisant un autr NAS synology 2 baies que je n'utilise pas sur lequel je peux faire un reset et lancer une nouvelle configuration avec le western digital pro. N'est-il pas préferable de retourner le disque dur RED PRO( je peux encore le faire) pour un RED PLUS similaire aux quatres autres .J'avais pris le Pro car plus durable en terme de longevité parait-il ?

Bonjour @STEPH 78 , Pour moi ton souci d'ajout de disque a ton groupe de stockage vient de la version du DSM. En effet il existe une version du DSM qui bloque les disque tiers ( hors ceux vendu part synology). Pour supprimer cette restriction il faut passer en DSM 7.3.xx Cette restriction est apparu à un moment mais vu le tôlé, fiasco et la perte de crédibilité de Synology il sont revenu dessus. Je te conseille donc de faire la maj de ton nas voir ici les différentes version à installer https://www.synology.com/fr-fr/support/download/DS1821+?version=7.3#system

Voici quelques captures d'ecran Le premier message s'affiche en avertissement en continuant et en suivant les recommandation abouti à un échec et au deuxième message. Merci de votre aide

Pour information, le support me confirme que l'utilisateur porteur du lien CMS entre deux instances de Surveillance Station ne doit pas être déclaré en 2FA : L'interface de connexion, bien qu'indiquant que la connexion est acceptée, ne la mémorise pas. Cela sera corrigé ultérieurement... Il convient donc de désactiver 2FA avant d'établir le lien, quitte à la réactiver ensuite. À noter que cet utilisateur peut tout à fait ne pas avoir les droits DSM.

Il faudrait des captures d'écran des messages concernés

Toutes mes excuses. Je ne suis pas un super habitué du Forum et ne connais pas grand chose à l'informatique . Le Nas est un synology DS 1821+, stockage en RAID 5, DSM 7.2.2-72806 Update 8

@STEPH 78 Merci de ne pas poster n'importe où ! Qu'est ce que ce message a comme portée dans la rubrique "News et infos" ? --> Je déplace, mais ce sera la seule fois. De plus, pas d'indication du modèle de NAS (8 baies c'est beaucoup trop vague), de la version de DSM, de la manière dont le stockage est constitué (SHR, JBOD, Raidxx, etc.) Mets toi à la place de ceux disposés à t'aider, ils ne peuvent pas "deviner" ce genre d'informations.

Bonjour à tous, je viens de recevoir mon disque dur western digital red pro 10 To pour augmenter la capacité de stockage de mon NAS synology 8 baies équipé de 4 disques durs Western digital red plus 10 To. Après avoir réalisé le formatage du nouveau disque dur, j'ai réalisé la procédure de rajout du disque dur neuf qui est reconnu (message m'indiquant que ce disque ne fait pas partie de la liste des disques durs recommandés par Synology) mais non intégré au volume de stockage existant. Le message suivant s'inscrit: "le système n'a pas pu étendre Groupe de stockage 1. Des problèmes de disques ont pu se produire pendant le processus d'ajout de disque" Y-a-t'il une manip que je n'ai pas faite? Y-a-t'il incompatibilité entre les disques, ou entre le disque neuf et le NAS? Faut-il que je retourne le disque neuf au vendeur pour acheter des western digital red plus? Merci de votre aide. Stéph78

À défaut de comprendre la différence entre le service HyperBackup et l’application HBVault, je comprends qu’un user HyperBackup n’a pas besoin du privilège DSM alors qu’un user Vault doit avoir ce privilège …

Merci pour ta patience … C’est clair ! Je me suis rendu compte fortuitement que si l’on ne coche pas la case permettant l’activation d’HSTS, on peut accéder au site en http …

Bonjour @church Je suis resté en DMZ, il faudrait que je prenne du temps pour me pencher sur le sujet bridge mais j'avoue que pour l'instant comme j'ai retrouvé un fonctionnement qui me convient je n'ai pas poussé plus 😅 avec la fonction relais IPV6 j'avais aussi ce temps de chargement d'environ 10 secondes

Les ports personnalisés sont les ports pour les applications. Ce sont ceux par défaut qui s'affichent et c'est là que tu peux les changer, ce qui ne sert à rien mais certains pensent que ça les protège. On se rassure comme on peut. D'autant qu'en passant par le revers proxy, le port de destination n'a vraiment plus aucune importance. A travers cette interface, tu as 2 méthodes pour accéder à l'application : soit par l'alias et à ce moment là ton url est https://ndd/alias, soit par un nom de domaine défini dans le domaine personnalisé et dans ce cas ton url est simplement https://tondomainepersonnalisé. Dans ton cas ton domaine personnalisé c'est cam.ndd. Perso je n'utilise pas cette interface. Je passe par le reverse proxy uniquement.

Merci ! Du coup, à quoi sert l’indication des ports 9900 et 9901 dans cette interface ? Devrais-je mettre 443 (et rien dans le port http). ?

Aucune. C'est une version plus user friendly. Cependant elle ne concerne que les applications du NAS. Pour les autres, c'est le reverse proxy de l'onglet avancé qu'il faut utiliser. Par exemple, ma domotique sur RPI est joignable via domo.ndd vers l'IP et le port du RPI. Idem pour pi-hole.

Pour ma culture perso, j’ai testé la configuration via le portail des applications. J’ai mis la configuration ci-dessous. Les ports 9900 et 9901 sont fermés sur la Box (et les 5000/5001 également) DSCam se connecte sans souci (et très rapidement) sans préciser de port, sur l’URL mentionnée. Quelle différence y a-t-il avec le reverse proxy ?

T'as passé la freebox en mode bridge ou t'es resté en double NAT avec une DMZ ? Le passage en mode bridge avec adressage des Next Hop vers l'adresse IPV6 Link Local du routeur est de loin la solution la plus propre, pour moi, afin de disposer de l'IPV6 sur tous tes VLAN via une délégation de préfixes. Avec la fonction relais IPv6, avais tu ce lag de 10s lors du zapping ?

Si j'ai bonne mémoire, il est dit dans le tuto de ne pas activer le http vers le https car cela pose (posait) des problèmes de redirection dans le reverse proxy. Je crois que c'est aussi dans ce même tuto qu'on parle d'un fichier .htaccess pour réaliser cette redirection. Mais comme les choses évoluent entre chaque version de DSM, il est possible que ce dysfonctionnement ait été résolu par Synology. Je ne comprends pas bien ta question. Si tu veux utiliser le reverse proxy pour joindre DSM, tu peux par exemple créer une ligne https:\\nas.ndd qui pointe vers localhost:5000. Perso, je ne suis pas friand d'un accès à DSM par le web. Aussi, j'ai rajouté un profil de contrôle d'accès limité aux seules IP privées et en secours à un nombre très limité d'adresses publiques que je possède. Je fais un accès à distance via wireguard sur mon routeur pour ensuite me connecter à DSM.

Oui il faut decocher la redirection http vers https car elle perturbe le reverse proxy. Pour l'acces à dsm (5000 ou 5001) il est préférable de ne pas l'exposer sur internet. meme derrière le reverse proxy. mais passer par un vpn.

Je n’avais vu cet aspect du tuto concernant l’inutilité du chiffrage sur le LAN. Même si c’est évident, je ne pensais pas que cela modifierait à ce point le délai de réponse de DSCam. Par extension, je m’interroge sur le 5001, désormais fermé. Y a-t-il des effets de bord à envoyer le reverse proxy sur le 5000 ? Sauf erreur de ma part, je n’ai rien vu à ce sujet dans le tutoriel. Faut il décocher la redirection http vers https ?

Rien d'étonnant. Déchiffrer puis re-chiffrer pour re-déchiffrer ça demande des ressources. Sauf si ton réseau local n'est pas sur, il ne sert à rien de passer en https en interne. Tout ceci est expliqué dans le tuto sur le reverse proxy. Alors ça a changé car jusqu'à présent les applications DS utilisaient le port de l'application par défaut. Si le port était différent, il fallait le préciser dans l'url. Et du coup, je me demande comment l'application DS sait qu'il faut passer par le 443 si le port n'est pas précisé. Peut-être que les deux sont testés : si le port par défaut ne passe pas, alors DS bascule sur le 443 (ou le 80 si http).

il l’était … il fait partie des ports que j’ai fermé. Je vais dans le doute tester sa réouverture le temps de faire un test. exact ! Merci . [EDIT] The winner is @Thierry94 !!! Le fait de modifier la règle du proxy inverse sur le port http 9900 au lieu du 9901 en https rend à DSCam sa rapidité d’avant ! J’ai du mal à comprendre pourquoi … À noter qu’auparavant, j’étais en direct sur 9901. Il semble que ce soit le fait de déchiffrer le 443 pour le rechiffrer en 9901 qui consomme.

Dans le reverse proxy il est inutile de mettre la redirection en https car tu es en local sur le NAS et la requette externe est déjà chiffrée. Il suffit d'ouvrir le port 9900 dans le portail des applications et de mettre https://ddns.443 vers http://localhost:9900

Le reverse proxy ne serait donc pas à l'origine des lenteurs. Saurais-tu reproduire les conditions dans lesquelles les flux apparaissaient au bout de 10 secondes ? Est-ce que le port tcp/5001 est exposé sur Internet ? Si oui, il faudra songer à le fermer rapidement.

Je me suis mal exprimé Le 9901 est bien fermé. Je l’ai réouvert temporairement pour vérifier si cela avait un impact sur le délai d’affichage des flux, ce qui n’est pas le cas Sur DSCam, une connexion à l’URL du reverse proxy sans préciser le port 443 abouti, même 9901 fermé Concernant mon dernier message, il faisait référence à des flux que j’affiche sur dSCam et qui proviennent d’un autre NAS connecté en VPN au premier (les flux vidéo passent par ce VPN)