-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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). ?
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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 ?
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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 ?
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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.
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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)
-
Mot de passe et clé de chiffrement non reconnu
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.
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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.
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
J’ai essayé de remettre le 9901 : pas mieux … J’ai réparé ma caméra HS : pas mieux Je manque d’idée ..
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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)) ?
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
-
Fermeture du port 9901 et passage par le reverse proxy : flux lents à apparaitre sur DSCam
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 ?
-
-
Mot de passe et clé de chiffrement non reconnu
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 ...
-
[Résolu]Accès Distant à Plex KO
Je me réponds à moi même sans être certain de ma réponse... Il semble qu'après avoir modifié le numéro de port à utiliser, il faut valider une première fois, puis arrêter et redémarrer le paquet Plex. En tous cas, cela fonctionne désormais, sans aucun port Plex ouvert
-
Mot de passe et clé de chiffrement non reconnu
Bonjour, Je sauvegarde les données bureautiques de mon DS718+ sur un DS124 avec Hyperbackup. J'ai défini une sauvegarde chiffrée dont j'ai noté la clé de chiffrement (et conservé son pendant le fichier .pem ). Sur Hyperbackup Vault du DS124, lorsque je veux visualiser la tâche, je dois renter la clé. Elle m'est refusée (yc si je l'exporte depuis le DS718+) Une idée ?
-
[Résolu]Accès Distant à Plex KO
Bonjour, J'utilise un serveur Plex sur chacun de mes NAS, chacun installé directement en tant que paquet (sans VM ni Docker). Chaque NAS est derrière sa Box, elle-même en Fibre sans CGNAT. IPv6 est ouvert et utilisé en priorité, avec Fallback en IPv4. Je suis en train de faire le ménage dans mes ports ouvert et ai donc utilisé le reverse proxy pour envoyer https://plex.DDNS:443 vers https://localhost:32400 (auparavant, j'utilisais un port spécifique en 32xxx, directement NATé sur mes Box) Cela fonctionne sur l'un de mes deux sites, pas sur l'autre... Une idée ?