.Shad.

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. 🤔

Les disques défaillants ce n'est vraiment pas rare non, mais on obtient généralement assez facilement un remboursement ou un échange si on peut le prouver avec un test fait par le logiciel constructeur. Si tu as commandé sur Amazon, ils n'y regardent même pas, tu dis que ça ne marche pas et ils te le remplacent... Le transport y est pour beaucoup, et corollairement la qualité de l'emballage.

Bonjour @rodo37 Petit problème de couleur de police quand on veut insérer du code : La sélection a été faite sur Bash dans ce cas-là, et quand on reclique on constate bien qu'on est sur Bash, mais le texte n'est pas lisible. Reproduit sur Edge et Chrome.

Bienvenue parmi nous 😉

Les réseaux que tu vois dans IP source ce sont des réseaux réservés à un usage privé, donc que tu ne trouveras jamais sur Internet. Ca permet donc à tous tes périphériques locaux d'accéder au NAS. Les règles sont parcourues dans l'ordre, donc il va autoriser les 3 premières règles, et tout le reste sera refusé avec la 4ème. Si plus tard tu comptes autoriser une utilisation distante pour certaines applications, il faudra les autoriser et les placer en amont de la dernière règle, car tout ce qui sera placé après ne sera pas pris en compte.

C'est toujours bien de pouvoir éviter le double NAT. 👍

Pour l'accès extérieur, est-ce que tu as bien un NAT sur ta box du port HTTP ou HTTPS de WebDAV vers ton NAS ? ou utilises-tu un proxy inversé ? Si ce n'est pas fait, tu ne pourras pas y accéder. En utilisation locale, ça marche car je pense que ta box doit faire du loopback (elle détecte que ta requête te fait revenir chez toi par l'extérieur, du coup elle prend un raccourci et va direct au NAS).

Les contrôleurs récents (depuis un paquet d'années déjà en fait) détectent si le câble est droit ou croisé et s'adaptent. Si tu synchronises un dossier sur le disque du PC (et pas sur un disque USB), et que tu réalises une copie de fichier volumineux, est-ce que tu as le même problème ?

Le .htaccess n'a d'intérêt que si tu souhaites rediriger tes requêtes HTTP vers HTTPS, car un proxy inversé est plutôt utilisé en HTTPS qu'en HTTP (au moins pour un accès extérieur). Tu peux parfaitement t'en passer, surtout si tu utilises des favoris pour naviguer. Le tutoriel que tu as cité, bien qu'intéressant, est moins complet que celui-ci, et tu n'as pas du tout besoin de lire les 34 pages. Si tu as un souci, pose ta question. Tu te doutes bien que sur 34 pages, il y a eu beaucoup de redite, mais on ne peut pas demander aux gens de lire 34 pages de commentaires, à la limite faire une recherche (l'outil est très performant).