.Shad.

Un serveur DNS IPv6 ce n'est pas copain avec les périphériques Android, donc à prendre en compte. Il vaut mieux utiliser SLAAC, on a moins de contrôle sur les IPv6 mais c'est pris en charge par tous les périphériques normalement.

Bienvenue parmi nous !

Je crois que @Phylloxou a bien compris le problème, je ne vois pas de solution facile à mettre en place avec ta configuration. Comme un intervenant précédent je pense que le besoin de cette bande passante est surtout une envie plutôt qu'une nécessité. 😉 Je pense que tu devrais en revanche essayer de poser tes questions sur les forums de lafibre.info, il y aura peut-être des gens qui seront plus à même de t'aiguiller. Je ne pense pas que tu sois le premier à vouloir tirer partie du débit partagé de ta box.

Perso je fais avec les listes de bases, pour justement éviter le blocage à outrance et les faux-positifs.

Salut à toi et bienvenue ! 🙂 Joli parc de caméras. 😉

Tiens, Grafana intègre une UI maintenant pour bâtir les requêtes sous Influx 2.0 ? ou toujours sous forme de code ?

Bienvenue !

Tu tentes de synchroniser en local ou à distance ? Je crois voir une adresse Quickconnect dans ta barre d'adresse ? File Station est un explorateur de fichiers, Drive est un outil de synchronisation des données, ça n'a pas grand chose à voir. Il y a un journal des modifications pour Drive, tu vas sur DSM -> Démarrer -> Console d'administration Drive -> Journal et tu fais une impression d'écran.

Bienvenue parmi nous !

Bienvenue !

Bah il est quand même dans la catégorie Plex Media Server, et "library" ou "bibliothèques" sont des termes adaptés à Plex. 🙂

Je veux bien que tu m'expliques comment voir et lire les ACL, j'ai jamais su avoir autre chose que le "+" en fin de permissions. C'est bien la magie du truc, et c'est pour ça généralement qu'on n'utilise pas l'utilisateur admin pour exécuter un conteneur. Car il pourra faire ce qu'il veut sur les volumes de l'hôte montés dans le conteneur. Utilisateur sans droit particulier ou utilisateur spécifique avec les droits minimum pour la bonne exécution du conteneur.

C'est exactement ce qu'il se passe pourtant. Avec le PUID et PGID on mappe un conteneur et un groupe de l'hôte vers le conteneur. Il n'y a pas de question de mot de passe quand tu tentes d'accéder à un fichier sous Linux. Si tu essaies de parcourir avec un utilisateur lambda un dossier avec des permissions rwxrwx--- appartenant à root:root, tu auras un message de refus. A aucun moment on te demande un mot de passe, sauf si tu invoques le mode super-utilisateur via "sudo". Mais c'est sudo qui amène une invitation de mot de passe, pas le fait de lire, écrire ou traverser/exécuter. Je ne sais pas si ça répond à ta question, si pas une impression d'écran illustrant ton interrogation m'aiderait à mieux cerner ta demande.

Salut, Je comprends bien ce que tu essaies de faire, je trouve par contre que ça complexifie énormément ton réseau, es-tu certain que ta box ne gère pas l'aggrégation de liens ? Ca simplifierait beaucoup les choses. De ce que j'en comprends, et dans ton infra actuelle, ta seule solution serait de passer par les IP pour tes montages SMB plutôt que par les noms Netbios, qui au passage sont un sujet à part du système DNS, Netbios étant limité au réseau local.

Je t'avoue n'avoir jamais testé un docker-compose logs -f sur un fichier docker-compose multiple. 😉 Je te propose de me dire ce que tu obtiens en faisant : docker logs influxdb -f Tu devrais obtenir quelque chose d'équivalent à ce que je montre dans le tutoriel : telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 109.726214ms telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 144.489076ms telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:52Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 145.368898ms telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 119.228603ms telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics

Bienvenue parmi nous 😉

Et du coup ? Ça marche ? Pas bien suivi si c'était juste une remarque de ta part ou une question 😉

Et ? Les champs sont remplis comme proposé dans le tutoriel et dans mon dernier message ?

Ben comme tu dis ça permet de voir autre chose que des IP, généralement les périphériques émettent leur propre nom d'hôte auquel vient s'accoler le domaine local poussé par le serveur DHCP. Ce que j'ai chez moi, et je me rends compte que j'ai oublié de parler des autres champs dans Conditional Forwarding que le deuxième. 😄 Le premier champ est nécessaire, il définit le sous-réseau que tu utilises dans ton réseau local. C'est bien expliqué dans le paragraphe descriptif de l'impression d'écran. Le nom de domaine n'est normalement pas nécessaire, si pas ça se trouve normalement dans les infos de ton serveur DHCP.

Je ne sais pas si c'est ton impression d'écran qui est rognée, mais dans le message d'erreur, il est impossible de lire le chemin après "bind mount failed". Si tu peux publier ton docker-compose complet. Dans ta deuxième impression d'écran ce n'est pas l'intitulé des variables d'environnement que tu dois mettre, mais directement leurs valeurs, ça correspond à ce que tu as entré dans les variables d'environnement d'InfluxDB : - INFLUXDB_DB=nas_telegraf - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf

Bienvenue parmi nous !

Réglage par défaut : chez moi c'est coché.

@axb J'ai l'impression que dans ton impression d'écran suivante : Tu as mis dans source le domaine xxx.synology.me, et ça ne peut pas marcher ainsi. Quand tu crées une entrée de proxy inversé, il faut que ce soit de la forme yyy.xxx.synology.me, par exemple pour accéder à dsm tu peux utiliser l'adresse dsm.xxx.synology.me. Car pour que le proxy inversé sache où rediriger la bonne requête, il lui faut une indication, et celle-ci sera justement le sous-domaine "dsm" que tu vas indiquer dans ton adresse. Quand il voit dsm.xxx.synology.me sur le port 443 (HTTPS), il va remarquer que ça correspond à un de ces enregistrements et rediriger comme il se doit. C'est là que survient le second problème, qui n'empêche pas le fonctionnement, mais qui est inutile, ta source est en HTTPS. Entre le proxy inversé et le service vers lequel tu rediriges tu restes dans le même réseau local généralement, ici tu restes même sur la même machine, tu n'as donc aucune raison de chiffrer en boucle locale. Donc dans destination, n'utilise pas le protocole et le port HTTPS, mais HTTP. Disons au hasard que tu as choisi 64080 pour DSM HTTP et 64443 pour DSM HTTPS, tu redirigeras vers http://localhost:64080 (Il n'y a au passage aucun intérêt à masquer ces ports...). l'adresse xxx.synology.me servira simplement à faire pointer vers ton IP publique en extérieur, et vers ton NAS localement par le serveur DNS. Il faudra ajouter dans ta zone DNS locale un enregistrement de type : dsm.xxx.synology.me CNAME xxx.synology.me Pour la zone publique, elle est gérée par Synology, qui y ajoute automatiquement les domaines demandés lors de l'obtention d'un certificat Let's Encrypt depuis ton NAS. Si tu demandes un certificat wildcard, ce sera plus simple, et tous les domaines *.xxx.synology.me pointeront vers ton IP publique, en plus que cette opération ne demande aucune ouverture de port sur ton NAS. Ainsi si tu crées des services à la volée que tu souhaites placer derrière ton proxy, tu n'as pas besoin de redemander un certificat.

On ne met pas de port dans une requête nslookup, juste un domaine. Donc tu enlèves les : et le port.

Le support Synology t'a juste donné une réponse bateau pour le coup. Si ta zone est bien définie telle que ton impression d'écran le montrait, et qu'un nslookup www.google.fr (ou n'importe quel autre domaine) renvoie comme serveur DNS résolveur ton NAS (UnKnown / 192.168.50.92) alors je ne comprends pas que ton IP publique soit renvoyée. Est-ce qu'on est bien d'accord que le domaine xxx.synology.me renseigné dans Panneau de configuration -> Accès externe, correspond bien au domaine renseigné sur le premier champ de ta zone : La première étape c'est d'arrive à obtenir un renvoi d'IP privée sur ce domaine-là via un nslookup. Pour t'assurer que la réponse ne vient pas d'un cache résiduel du DNS, tu peux te connecter en invite de commande Windows et taper : ipconfig/flushdns Tant que http://xxx.synology.me:64yyy ne t'envoie pas vers DSM, il ne faut pas essayer d'aller plus loin. Pour la partie proxy inversé, il y a plein de choses qui ne vont pas, je te conseille de supprimer l'entrée que tu as créée dans Panneau de configuration -> Portail des applications -> Proxy inversé. Et décoche la case "Rediriger ... HTTP vers HTTPS ..." dans :