Toutes les discussions

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)

Voici un extrait de mes derniers échanges avec le support. Je ne suis pas encore certain de bien comprendre … moi : Je pense avoir trouvé une piste : Toutes mes sauvegardes sont effectuées par un user spécifique du groupe admin (Sauvegarde) dont les droits sont strictement limités à la sauvegarde. Ce user n’a pas les droits DSM. pour vérifier les sauvegardes, je me connecte avec un autre user du groupe admin ayant un accès complet au NAS. Ce user ne semble pas pourvoir accéder aux sauvegardes qu’il n’a pas créé lui même via HyperBackup Vault. Il ne les voit que via HyberBackup. si je donne les droits DSM aux user Sauvegarde , HyperBackup Vault ouvre correctement les sauvegardes chiffrées. je ne comprends pas cette logique. Wayne Z. 2026-05-15 19:03:18Bonjour, C'est une excellente analyse de votre part. Votre observation confirme précisément pourquoi nous voyions des erreurs « Permission denied » dans les journaux système alors que vous êtes pourtant membre du groupe administrators. Voici l'explication technique de cette « logique » qui peut paraître déroutante : 1. Distinction entre accès aux données et privilèges d'applicationDans DSM 7, être administrateur ne donne plus automatiquement tous les droits sur toutes les applications pour des raisons de sécurité renforcée. Hyper Backup (Source) : C'est un service système. Il accède aux fichiers pour les envoyer. Hyper Backup Vault (Destination) : C'est une application interactive de DSM. Lorsque vous essayez de « Vérifier » ou de « Parcourir » une sauvegarde chiffrée dans l'interface du Vault, DSM lance un processus au nom de l'utilisateur connecté pour tenter de déchiffrer l'index. 2. Le conflit de droits que vous avez identifiéSi la tâche a été créée par l'utilisateur Sauvegarde : Les dossiers internes de l'archive (comme le fameux dossier @writer vu dans les logs) sont « la propriété » de l'utilisateur Sauvegarde. Si cet utilisateur Sauvegarde n'a pas l'autorisation d'accéder à DSM (Privilèges d'application), le système restreint les capacités du paquet Hyper Backup Vault à manipuler les métadonnées de cet utilisateur dans l'environnement de bureau DSM. C'est pour cela qu'en lui rendant ses droits DSM, le Vault parvient enfin à « lier » les droits de l'utilisateur aux fichiers de l'archive et autorise le déchiffrement.

Si tu ne précises pas le port, l'application DS Cam utilise le port par défaut : 9901. Ton ndd est normalement liée à ton IP publique. Donc, en ne mettant pas le 443, DS utilise par défaut https:\\cam.ndd:9901. Comme le port est ouvert dans ton routeur, il est normal que ça fonctionne. Et par la même occasion, tu ne passes pas par le reverse proxy ce qui exclu de facto toute probabilité de ralentissement de sa part 😀

Merci Mic13710 Je ne vois pas trop de différence en précisant le port 443 Pourrait-il y avoir un effet de bord de la fermeture du 9901 sur la box distance (j’agrège des caméras de trois sites, donc 3 NAS, dont l’un via un VPN. Je n’ai rien touché dans le VPN. Normalement, le 9901 y est toujours ouvert. Le Firewall est ok.

Je ne crois pas que le reverse proxy soit la source de ton problème. Est-ce que tu as bien spécifié le port dans DSCam ? Même si tu utilises le 443, il faut le préciser dans les applications DS. https:\\cam.ndd:443

J’ai essayé de remettre le 9901 : pas mieux … J’ai réparé ma caméra HS : pas mieux Je manque d’idée ..

Bonjour à tous, En premier lieu, mille excuse pour le sujet car il a surement été traité mais je n'ai pas réussit à le comprendre ! J'ai un DS920+ en Local pour la sauvegarde des photos/video/important ( Volume1) et pour le multimédia (film, série.. en Volume 2). Le NAS n'est pas exposé au net mais uniquement en local. Je possède un espace Pcloud (oui, je sais, c'est pas le meilleur :( ...) Bref, j'ai voulus mettre en place avec Sync Cloud la sauvegarde unidirectionnelle du volume 1 vers Pcloud ; mais le problème de webdav Pcloud m'empêche de faire cette sauvegarde correctement. J'ai vu qu'il fallait passer par un docker et Rclone pour que cela fonctionne. J'ai donc farfouillé et j'ai trouvé comment faire l'install de rclone (j'ai jamais utilisé docker donc dur à comprendre le truc au début). Bref, je suis passé par Container Manager de Synolody, j'ai pris l'image Rclone et installé. Mais à la page de la création, je bloque complètement. J'ai tout un tas de paramètres et j'avoue que pour beaucoup, je sais pas trop ce qu'il faut y mettre ! Je vosu mets les deux screens qui me bloquent. Du coup, je vous appelle pour un petit coup de mains à la configuration. Pouvez vous m'aiguiller ? Par avance, Merci PS : j'ai créé le fichier .conf de RClone.

Merci ... Je dirai que ce n'est pas mieux ... Toutefois, j'ai une caméra concomitamment (et sans rapport) hors service. Serait-il en attente d'un TimeOut sur cette caméra avant d'envoyer les flux (DSCam mouline puis tout d'un coup affiche mes 7 flux (enfin 6 depuis qu'une caméra est HS)) ?

Oui

Cela me dépasse un peu ... Je mets quoi ? ça peut être ?

Essaie d'activer les websocket dans les en-têtes personnalisées.

Bonjour, Tout est dans le Titre ... J'essaie de fermer tous les ports que je peux fermer et d'envoyer le trafic sur une URL du reverse proxy en 443. J'ai donc créé une entrée du reverse proxy sur https://ss.DDNS:443 qui pointe vers https://localhost:9901. ça fonctionne (DSCam se connecte bien). Mais les flux vidéo mettent une trentaine de secondes à apparaitre, contre env. 10 secondes auparavant. Une relation de cause à effet ?

Je tombe sur cet article de 2023 qui semble correspondre à ce problème. Nous sommes en 2026, et ce n'est pas résolu ??? Bref, j'ai ouvert un ticket ...

Moi aussi je suis de cette génération... Bienvenue @Le Bleu B. . Tu verras on apprend en faisant.

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.

Je ne comprends pas la réponse du support. Votre shr actuel est construit avec des disques de 10.91To. Les 0.01To de différence du disque de 10.92 ne sont pas utilisés par le SHR. Seule la capacité utilisée doit être prise en compte, pas la capacité réelle de chaque disque. Ne serait-ce pas plutôt un problème sur le nouveau disque ? l'avez-vous testé en profondeur avec le logiciel du constructeur ? Si le disque est ok, vous pouvez tenter une autre méthode, sans aucune garantie. Ce n'est pas sans risque puisque vous dégradez votre groupe. Vous sortez le disque de 10.92To, vous réparez avec le nouveau disque puis vous construisez votre shr2 avec le 10.92To préalablement formaté. Mais avant cela, si vous savez vous connecter à votre NAS en ssh, postez le résultat de cette commande qui va donner l'état de vos raids : cat /proc/mdstat

Bonjour, le sujet est assez ancien, mais depuis il y a une nouvelle app depuis qui permet de faire de la synchronisation bidirectionnelle entre un téléphone android et un NAS (paramétré en webdav) : il s'agit de EasySync. Petit bonus, elle est open source...

L'assistance Synology m'a répondu lundi. Le problème viendrait de la capacité de mes 5 disques : sur le SHR-1 exixtant, j'ai 4 disques : 2 Seagate Entreprise reconditionnés de 10,91 To et 2 WD Red de 10,92 To Le 5eme disque que je souhaite utiliser pour la migration est un Seagate (neuf) de 10,91 To. A cause de ces 0,01 To de différence, le système bloque. 2 solutions proposées : Refaire le volume directement en SHR-2 : ceci impose que je sauvegarde mes 22To sur une autre support avant de supprimer le volume et le recréer Acheter 2 nouveaux disques de capacité d'au moins 10,92 To (mais actuellement à 450-500€ le disque WD, ca pique ! J'ai trouvé le nouveau Seagate à 370€) Je cherche un NAS ou des disques en prêt pour 1 mois (je suis en déplacement toute la semaine donc, je ne peux faire les transferts que le WE) avec plus de 22To de capacité (il me reste 3 bais de libres) Sinon, ouvrir un cloud pour 1 mois de plus de 22To, il faut compter (de souvenir) 175€ le mois sur Synology C2