.Shad.

Salut, bienvenue parmi nous. Il est intéressant que tu dises quel modèle de NAS tu possèdes de manière à ce qu'on adapte nos réponses à ses possibilités.

La section Networks ne concerne que les routeurs USG ou USW. Si tu as juste des points d'accès cette section ne sert à rien (c'est tordu car généralement tu as un flag USG pour indiquer que c'est une fonctionnalité qui ne concerne pas l'AP).

Bienvenue parmi nous 🙂

Bienvenue parmi nous 🙂

Je viens de tester sur mon NAS, le snmpwalk marche très bien, que ce soit l'adresse IP locale ou l'adresse passerelle. Essaie avec localhost ? Est-ce que "public" est bien le nom de ta communauté ? Pourquoi tu as à la fois l'IP locale du NAS et l'adresse passerelle ? tu pointes vers le NAS dans les deux cas.

Tu exécutes la commande depuis une session SSH du NAS ? Ou une autre machine du réseau ? PS : Évite d'utiliser le protocole SNMPv1 -v1, utilise plutôt -v2c

Là comme ça c'est difficile de t'aider, il nous faut plus d'éléments : est-ce qu'un ping de l'IP du NAS fonctionne ? Est-ce qu'il a déjà fonctionné normalement par le passé ? Un reset simple mode 1 pourrait peut-être résoudre le problème (reset des credentials + config réseau). Tu trouveras plus d'infos sur le reset mode 1 sur le site de Synology.

Bienvenue parmi nous ;)

Ca demanderait beaucoup plus d'explications et d'expertise pour te faire un exposé fidèle. Mais grossièrement les OID renferment les valeurs qui caractérisent ton système. Les OID sont une arborescence, on le voit bien ici : https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_MIB_Guide.pdf La colonne "Name" correspond au MIB, une désignation qui permet d'identifier plus facilement la stat recherchée qu'une suite de chiffres qui n'ont rien d'intuitif. Quand tu fais un snmpwalk, le système va sonder le périphérique et te renvoyer tous ses OID. Si tu disposes des MIBs adéquats au périphérique (si mis à disposition par le constructeur), le snmpwalk sera "traduit" et te permettra d'identifier plus facilement ce qui est quoi. Plus d'infos ici : https://www.comparitech.com/net-admin/snmpwalk-examples-windows-linux/#:~:text=snmpwalk is the name given,SNMP data from a device.&text=An OID is an object,within an SNMP-enabled device. Par exemple, D-Link, quand j'ai regardé du moins, ne mettait pas de MIB à disposition pour ses switchs, du coup j'avais bien réussi à faire un snmpwalk dessus, mais ça ne m'a pas beaucoup aidé. 😄 De ce que j'ai pu lire, c'est plus compliqué avec SRM qu'avec DSM, je ne peux malheureusement pas t'aider là-dessus outre mesure, je n'ai pas de RT. 🙂

Bonjour à tous, Je souhaiterais savoir s'il est possible de déplacer le dossier de destination des logs S.M.A.R.T. Actuellement, ceux-ci se trouvent dans /volume1/document/logs s.m.a.r.t/ J'utilise Resilio-Sync pour synchroniser mes documents importants dans /volume1/document/, et ce dossier et son contenu appartiennent à root:root. D'où le fait que j'ai des erreurs de synchronisation à cause de permissions insuffisantes (logique). Je pense que c'est un réglage que j'ai dû faire, mais en reparcourant les tutoriels je n'ai rien vu à ce sujet. Si quelqu'un a une piste, je suis preneur, j'ai déjà regardé ici : Mais je n'ai pas trouvé d'option quelconque pour définir un emplacement.

Pour l'instant je trouve ça assez bien fait, en tout cas ça compense les problèmes qu'on peut avoir sur mobile avec la nouvelle mouture du forum (notamment la partie notifications, messages privés, etc...). C'est sobre et efficace, voyons comment ça évolue.

Bienvenue !

Si ton IP est dynamique, il te faudra alors utiliser un DDNS et un nom de domaine (Synology en fournit un gratuitement). Voir le tutoriel :

Ca ne va pas forcément coincer. J'ai par exemple Baikal (serveur CardDAV/CalDAV) qui utilise l'uid/gid 33. C'est un utilisateur réservé à DSM normalement, mais ça n'empêche pas de fonctionner, tant que tes volumes ont été chownés pour cet uid/gid. Il faut juste regarder les droits que ça implique sur ces fichiers. Ca donne la main à Portainer sur le socket Docker local. Il n'est utilisé nulle part, vu que tu n'utilises pas l'image de sjawhar et que Docker n'est accessible qu'en local (pas d'argument tcp au lancement). Donc même si tu l'exposais, ça n'aurait aucun effet.

Clair et concis. 😄 Plus sérieusement, sans nous raconter ta vie, le but est aussi de connaître ton matériel, l'utilisation que tu en fais, et ton niveau général en informatique et/ou réseau. Tout cela nous permet d'adapter nos réponses.

Salut, Il existe une ribambelle de solution. Dire quelle est la plus simple c'est très subjectif : VPN : tu connectes ton Windows en tant que client au serveur VPN de ton NAS, du coup les deux causent comme s'ils étaient en local, tu peux utiliser SMB ou NFS pour connecter un lecteur réseau de Windows sur le NAS. SFTP : tu installes ça sur ton Windows, et tu fais un script pour y copier des fichiers (tu trouveras des tas d'exemples en cherchant un peu sur Google "SFTP script". SSH : tu installes un serveur SSH sur Windows, et tu copies les fichiers par la commande "scp".

Dans ton log, toutes les références à "uap" ça ne concerne pas plutôt une borne unifi ? Il y a aussi visiblement une erreur avec le script Python, mais l'essentiel du log concerne la borne unifi. Telegraf essaie de scanner par SNMP la borne Unifi à "uap1" et "uap2", chose que le résolveur interne (le lookup sur 127.0.0.11:53) ne peut pas connaître. Un conteneur en mode bridge essaie de résoudre par lui-même les requêtes DNS, requêtes transmises à l'hôte quand il n'en est pas capable. Est-ce que le NAS sait résoudre "uap1" ? A vérifier avec un nslookup. Sinon en entrant l'IP des bornes unifi ça devrait être bon normalement. Dans un de tes précédents posts on voit que c'est le unifi_telegraf qui récolte un 401. Et fbx_telegraf donnait un code 204. Qu'en est-il maintenant ?

Bienvenue parmi la communauté 😉

Bienvenue 😉

Pas du tout. Ce que je dis c'est que le conteneur issu de l'image sjawhar/docker-socket-proxy permet d'exposer le socket Docker d'une machine B sur un port TCP, sans que le démon n'ait été, au lancement de la machine B, configuré pour exposer autrement qu'en boucle locale (donc accessible uniquement depuis cette machine). Et ce, de manière chiffrée par le biais d'un certificat. Portainer facilite la connexion d'une instance Docker à une autre par une interface, mais on peut très bien le faire uniquement en lignes de commande. Le fait d'avoir monter un dossier du NAS (/volume1/docker/portainer/data) dans le conteneur (/data) permet d'avoir une persistance des données, car même si le conteneur est supprimé, le contenu d'un dossier n'est pas supprimé. Si on ne met rien dans la partie volumes, alors Docker créera aussi des dossiers, dans dans un chemin invisible à l'utilisateur depuis DSM (/var/lib/docker/...), et qui s'effacera quand le conteneur disparaîtra. Quand rien n'est précisé au niveau de l'utilisateur, l'image crée les fichiers et dossiers avec le même UID/GID que celui utilisé dans le conteneur (c'est souvent là que ça rentre en conflit avec les NAS), et est exécutée par l’utilisateur root. C'était pour la littérature que je l'évoquais, par rapport à ta question, un conseil laisse ça de côté pour le (un bon?) moment. 😉 Non du tout, ce que tu fais là, mais je l'ai rappelé juste avant, c'est pour assurer une persistance des données, c'est tout. Dans ton exemple de NAT, remplace la box par ton NAS, et ton NAS par le conteneur, et tu as exactement le même fonctionnement. Quand tu écris : ports: - 18096:8096 tu dis que le port 18096 de ton NAS doit rediriger vers le 8096 du conteneur. Donc en tapant dans un navigateur : IP_du_NAS:18096, tu déboucheras sur ce qu'on trouve à IP_du_conteneur:8096. Un conteneur est, par défaut, créé dans un sous-réseau privé, auquel seul le NAS, si les règles de pare-feu le permettent, peut y accéder. Donc si tu essaies de t'y connecter depuis un PC sous Windows par exemple, c'est le NAS, à la manière d'une box, qui fait office de passerelle et rend les services que tu souhaites accessibles.

On parle du socket Docker, c'est le fichier /var/run/docker.sock. Quand DSM démarre Docker, ça revient à lancer la commande : dockerd -H unix:///var/run/docker.sock Ici on ne charge que le socket UNIX, il est donc inaccessible de l'extérieur. il est possible d'écrire aussi : docker -H tcp://0.0.0.0:2375 ps et dans ce cas-là on rend le socket Docker accessible à toutes les IP sur ce port (localement par défaut, ou à distance si on fait du NAT). La méthode que je propose émule ceci : dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem \ -H=0.0.0.0:2376 On expose le socket Docker via TCP sur le port 2376, mais sur un port sécurisé qui nécessite d'avoir les certificats clients qui correspondent aux certificats serveurs qu'on charge au démarrage. Plus d'infos : https://stackoverflow.com/questions/35110146/ https://docs.docker.com/engine/reference/commandline/dockerd/ https://docs.docker.com/engine/security/https/ Mais vu qu'il est compliqué sur Synology de lancer Docker via des arguments que ceux prévus par DSM, on passe par ce conteneur qui permet d'exposer le socket local via le port 2376, sans pour autant toucher à la commande DSM, c'est transparent. Attention, il faut que le créateur de l'image ait prévu de telles variables, ce n'est pas courant en réalité. Le moyen de forcer l'emploi d'un utilisateur c'est : environment: ... user: "uid" # ou "uid:gid" volumes: ... En l'occurrence Portainer n'intègre pas ces variables d'environnement. Ça crée un conteneur directement depuis une image officielle. Je n'ai jamais essayé de m'en servir car jamais eu besoin, je pense que c'est plus utile pour du développement. Portainer-ce est principalement focus sur Kubernetes (K8s), qui est un concurrent de Docker qui est très utilisé dans les entreprises, ça n'a pas beaucoup de sens pour une utilisation en tant que particulier, sauf pour le côté ludique. Si tu as fait un NAT entre le NAS et le conteneur docker-socket-proxy dans ton fichier docker-compose, il est accessible sur ton NAS. Pour qu'un périphérique autre y accède (par exemple l'hôte qui héberge Portainer), il faut que Portainer se connecte à IP_NAS:2376.

Sauveur carrément ! 😄 De rien 😉

La règle Tous/Tous/Refuser invalide tout ce qui se trouve après. Les priorités sont de haut en bas. Il faut donc placer cette règle tout en bas de la liste. PS : La règle Tous/Tous/Refuser inclut Tous/Russie/Refuser, donc avoir les deux ne sert à rien.

Je veux bien la source car je n'ai rien trouvé qui semble laisser penser que Portainer ait mis en place un système de PUID/PGID (pour éviter de chmod-der les dossiers en fait). J'ai trouvé ça qui dit que ça n'est pas prévu, mais ça date cela dit : https://github.com/portainer/portainer/issues/1535 Pour le port 8000, c'est pour ce qu'ils appellent le Edge Agent, ça ne nous concerne pas a priori (aux dires de leur doc), donc aucun besoin de NAT ce port sur le NAS. On ne NAT que ce dont on a besoin. Dans le cadre d'un réseau local, le besoin de sécurisation est moins prégnant car le postulat de départ est de supposer le réseau local comme sécurisé. Reste qu'exposer le port 2375 (non sécurisé) pour un accès distant au socket Docker, c'est donner un accès potentiellement root à n'importe qui (ou quoi, malware compris) sur le Docker de la machine en question, et ça peut très vite se transformer en root sur la machine. Sans mot de passe on entend bien. Donc ce serait l'équivalent de ne pas mettre d'utilisateur ni de mot de passe à DSM pour tous les périphériques de ton réseau local. Faut déjà un sacré niveau de confiance quand même. L'idée ici est de mettre en place une liaison TLS client-serveur basée sur des certificats auto-signés, et surtout définir quelles IP et quels noms de domaines peuvent accéder à l'instance qu'on désire connecter. Et ça évite surtout d'exposer nativement le socket aux requêtes externes. En effet, quand DSM lance Docker, il n'est accessible qu'en boucle locale. Si on veut l'exposer sur un port, il y a un argument à ajouter tcp://0.0.0.0:2375 (ou quelque chose du genre) pour le rendre disponible au lancement du démon. La modification de ce paramètre dans les tréfonds du SSH ne survit pas à la plupart des mises à jour systèmes, et risque surtout de faire planter ton NAS. Ici, l'image de sjawhar fait office d'intermédiaire entre le démon exposé localement, et l'instance de Portainer qui essaie d'y accéder. Pour désactiver cet accès distant il suffit de désactiver ce conteneur, c'est complètement transparent pour le démon. Donc aucun redémarrage, et aucune incidence sinon que tu ne peux plus y accéder sans te connecter à la machine via UI ou SSH. C'est pas forcément évident à comprendre, mais retient qu'il faut à tout prix éviter d'exposer le socket Docker autrement qu'en boucle locale, et que cette méthode permet tout de même un accès relativement sûr. Si on veut pousser la chose plus loin, on peut mettre en place un VPN sur l'hôte du socket Docker distant, et n'autoriser que les IP du réseau VPN. C'est toi qui choisis où tu places le curseur de sécurité.

Ben heu si tu actives le pare-feu et que tu veux accéder à ton NAS depuis ton réseau local (ce qui est généralement le but pour un particulier) si. 🤔