.Shad.

Ton NAS est dans la liste des modèles équipés des puces Intel défectueuses. Tu trouveras les tests à faire sur ce forum.

Je ne vois pas le rapport entre tes impressions d'écran et mes questions, j'ai bien compris que tu faisais du NAT x6690 -> 6690. De plus tu ne réponds pas à ma question :

En plus de la sauvegarde cloud je te conseillerais d'avoir un disque dur externe, pour restaurer rapidement au besoin, que tu aies une connexion Internet ou non. Suivant le budget, un DS218 pourrait convenir, éventuellement un DS220+ si les finances le permettent (je conseille malgré tout toujours les modèles "+" pour ne pas avoir de regret par après parce qu'on est limité par la gamme du NAS). Les modèles "+" ont l'avantage de pouvoir faire de la virtualisation et de la conteneurisation. Si un jour tu souhaites mettre en place une application qui n'existe pas sur DSM, ou qu'un paquet natif Synology n'est plus mis à jour tu pourras tout à fait émuler un système Linux classique ou directement l'application dont tu as besoin.

Oui enfin à partir du moment où on souhaite y accéder de l'extérieur, il faut que les accès à ton NAS soient sécurisés. Et ca va te demander un peu de lecture et de temps quand même. 😉 Pour le modèle de NAS, si c'est juste pour du stockage tu n'as pas besoin d'un modèle haut de gamme, sauf si tu désires utiliser ton NAS à d'autres fins par la suite (bloqueur de pubs, gestionnaire de mots de passe, home theater, etc...). Pense aussi à la sauvegarde de tes données, et la nécessité ou pas d'avoir une redondance de disques pour éviter les temps d'indisponibilité en cas de panne d'un disque. Et bienvenue 🙂

Tu as sûrement écrit les données du speedtest dans cette partition. Tu as bien tenté le reset mode 2 ? https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS#t3

Je veux bien voir un screen de l'endroit où tu modifies le port de transfert de données de Drive. 🙂 Si c'est dans Portail des Applications tu n'as pas compris ce que je t'ai dit alors. Ton plan marcherait si tu pouvais définir un port personnalisé de manière bilatérale. Vu qu'on parle de synchronisation avec Drive, comment le serveur en retour sait-il qu'il doit contacter ton périphérique sur le port 26690 ? Lui il cherche le port 6690 de ton périphérique, quand il tombe sur le pare-feu du service informatique, il est bloqué actuellement. De plus, un intérêt particulier à changer le port ? Imposé par le service informatique ? Il n'y a aucun gain de sécurité à faire cela. Pour vérifier l'ouverture d'un port, tu peux utiliser nmap ou telnet.

Il y a deux choses différentes : l'interface Drive accessible depuis DSM, via port personnalisé ou proxy inversé. Ça on peut le modifier. Puis tu as le transit des données, qui se fait via le port TCP 6690 comme l'a dit @pluton212+. Pour synchroniser à distance ce port doit être redirigé vers ton NAS depuis ta box. Et ouvert dans le pare-feu du NAS. Pour une utilisation locale, il suffit qu'il soit ouvert dans le pare-feu. L'adresse à entrer dans Synology Drive Client est juste l'IP publique ou le DDNS ou nom de domaine qui pointe vers cette IP, sans préciser de port. EDIT : A noter que pour une utilisation combinée locale et externe, tu peux utiliser un serveur DNS local pour ne pas avoir à changer l'adresse du NAS.

Non pas forcément. Autant c'est très utile en macvlan, autant en bridge je suis plus dubitatif, mais ça ne mange pas de pain, tu peux le faire si tu le souhaites. 😛

Wilkommen !

@oracle7 Pour ma part je n'ai jamais besoin d'utiliser les IP, car dans un réseau bridge personnalisé j'utilise uniquement les noms de conteneurs. Et dans le réseau bridge par défaut, 172.17.0.1, ce sont généralement des conteneurs qui : - n'ont pas d'interface (watchtower) - ont leur ports translatés sur l'hôte si je dois y accéder depuis l'extérieur (calibre-web, emby, etc... la plupart des applications) Donc pour moi ça n'intervient jamais. Dans quel cas as-tu l'utilité de contacter un conteneur par son IP ?

Moi non plus, j'ai modifié le tutoriel pour ne pas limiter la plage IP, ça n'a de toute façon pas beaucoup d'intérêt de le faire pour une utilisation en tant que particulier.

@RF-Atomik Tu peux essayer de supprimer le réseau monitoring actuel (il faut arrêter et supprimer tous les conteneurs qui en font partie avant via docker-compose down), via SSH c'est : docker network rm monitoring Puis tu le recrées mais cette fois-ci tu ne précises pas d'IP range, donc : docker network create -d bridge \ --subnet=172.19.0.0/24 \ --gateway=172.19.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring Et tu recrées tes conteneurs. C'est peut-être l'IP range qui fait déconner le truc, pour une raison obscure car chez ça marche, mais je vois dans tes commandes que les IP attribuées au conteneur sont dans la plage /24 au lieu de /28. @Jeff777 Là comme ça je n'ai plus d'idée, il faudrait que je prenne la main via Teamviewer à l'occasion.

Ce n'est pas sensé avoir de conséquence. Tu peux taper en SSH sur le NAS : docker network inspect monitoring et docker container inspect telegraf et poser le résultat ici.

Je n'ai pas compris ta phrase. Ah si, tu veux dire que ton PC a une adresse en 10.0.10.x ?

@MilesTEG1 Ce n'est pas le même volume, le volume qui se monte dans les dossiers cachés de Docker c'est un volume qui est exposé dans le Dockerfile et que tu n'as pas précisé dans le fichier docker-compose, va voir sur Github dans le Dockerfile de l'image concernée, tu verras sûrement d'autres volumes à la fin du Dockerfile, outre celui que tu as monté dans /volume1/docker/....

Bah ça vient avec l'expérience ça 😉 Ca n'a juste rien à voir avec ce que je t'ai proposé. Là tu utilises un volume de type "bind" sur l'hôte, moi je te parle d'un volume docker : https://docs.docker.com/storage/volumes/

@RF-Atomik Peux-tu taper en SSH : docker exec -it telegraf ping 172.19.0.1 - Ici telegraf est le nom du conteneur Telegraf - Ajouter sudo devant la commande si tu n'es pas connecté en root Est-ce que le ping est fonctionnel ?

@RF-Atomik Le nom de la communauté est le bon ? Si tu l'as changé, il faut le changer dans la partie [[inputs.snmp]] de la partie Synology dans le fichier telegraf.conf (On ne voit pas tes images) @Jeff777 Tu peux remettre ton fichier docker-compose pour telegraf sur le Rpi ?

Bon ben tu n'as qu'à le générer sur le NAS, c'est exactement le même (évite de prendre un ancien backup, la fichier évolue avec les màj), tu as juste à taper : docker run --rm telegraf telegraf config > telegraf.conf.rpi Tu le transfères et tu le renommes correctement sur le Rpi. Je suis quand même très étonné de ce problème que tu rencontres, mais je ne vois pas comment le debugger.

@RF-Atomik Passe par l'IP passerelle comme conseillé dans le tutoriel, comme ça tu n'es pas dépendant de l'IP locale. Dans le tutoriel je choisis le réseau 172.18.0.0, mais quelque soit le réseau choisi, c'est la première IP du réseau qui est la passerelle, 172.18.0.1 dans mon cas. Normalement si tu as autorisé la plage d'IP 172.16.0.0/255.240.0.0 dans le pare-feu du NAS ça devrait fonctionner. Pour ma part je supervise un autre NAS via son IP locale depuis le Telegraf de mon NAS principal sans problème.

Aucune raison que ça ne fonctionne plus, es-tu sûr d'avoir déclaré le volume correctement dans la section volumes du fichier docker-compose ?

@Jeff777 Si tu te log en root et que tu tapes la commande originelle : docker run --rm telegraf telegraf config > telegraf.conf Le fichier ne se crée pas non plus ? (penser à supprimer l'ancien avant) @RF-Atomik 10.0.10.41 c'est l'IP du NAS hôte ? ou d'un autre NAS ?

J'ai les mêmes messages, mais les volumes non utilisés sont liés à un autre conteneur, c'est une conséquence. Un conteneur crée des volumes, on peut voir ces volumes dans le Dockerfile : On voit tout en bas : VOLUME /config /sync Ca veut dire que si l'on ne monte qu'un des deux volumes, par exemple /config, dans notre fichier docker-compose, Docker va créer ce qu'on appelle un "volume" Docker qui comprendra les fichiers que l'image place dans /sync, et ce sera un dossier créé dans les répertoires dédiés à Docker, dans /volume1/@docker/... (qui est un lien symbolique de /var/packages/Docker/...) Ces dossiers sont non persistants, donc à chaque fois que le conteneur est supprimé, le volume n'est plus utilisé, à la recréation du conteneur, un nouveau volume sera créé. D'où la liste de volumes non utilisés, il suffit d'identifier quel volume de quelle image tu ne définis actuellement pas dans tes fichiers docker-compose. Pour éviter qu'ils aient un nom bâtard, et que les données persistent, c'est simple : version: ... services: blabla... ... volumes: - exemple:/etc ... volumes: exemple: Ca va te créer un volume Docker qui aura pour chemin : /volume1/@docker/volumes/exemple/_data/... Pour l'histoire des instances multiples, il faudrait aller voir sur le Github de Watchtower, je l'utilise sur 4 machines différentes et toutes ont ce message après mise à jour.

Ok je pense voir le problème pour docker-compose, l'installation a été faite pour l'utilisateur, pas le système. Donc tu tapes : pip3 uninstall docker-compose Je pense que tu avais oublié le "sudo" devant quand tu l'as installé. Ca n'explique pas les problèmes liés à Docker par contre. Donc je t'invite à tout désinstaller (suivre les liens données plus avant, modulo la commande sans le sudo au-dessus). Puis tu réinstalles tout en étant connecté avec pi, pas avec root. Toutes les commandes sont précédées de sudo. Logiquement ça devrait te permettre de repartir sur une base saine.

Ouh le vilain ! Bienvenue 😉