.Shad.

Je pense tout le contraire 🙂 DS Audio, DS Video, etc... il existe des alternatives bien plus au point sur le marché, et installables sur nos NAS. Qu'ils concentrent leurs ressources sur ce qui fait le cœur d'un NAS : son OS, sa stabilité et sa fiabilité. Et son évolutivité, accessoirement. Dans le cas de Photos, c'est un peu différent, car je dirais que c'est leur seule application qui se démarque par rapport à la concurrence (hormis Google Photos), il faut qu'ils poussent leur avantage comparatif sur ce point. Mais s'ils avaient des ressources illimitées je penserais comme toi.

Bienvenue parmi nous ! 🙂

Quelques questions à se poser avant : Est-ce que le port SSH de votre NAS est exposé publiquement ? Si oui, est-ce que le combo login/password est assez robuste ? Un paramétrage comme celui de @El_Murphy est ce qu'on attend classiquement sur un NAS, modulo les éventuels services que vous exposeriez publiquement, et dans quelle limite géographique. Pour mon VPS, le port 22 est exposé publiquement, mais ce n'est pas forcément un problème, il leur faut obligatoirement une clé privée dont la clé publique est enregistrée dans le trousseau SSH du VPS. Si on ajoute encore fail2ban à cela, sauf faille béante du paquet SSH, mon serveur ne court strictement aucun risque de ce côté-là. Et votre NAS dispose des mêmes mécanismes de sécurité, si vous les avez configurés, je ne vois pas de raison de s'inquiéter.

C'est ton IP publique, tu la trouves en allant sur tout un tas de sites comme https://ip.lafibre.info. Et sur le site que je t'ai donné il suffit d'y coller cette IP et le port que tu souhaites scanner. Les autres champs sont là par défaut, ils ne gênent normalement pas.

/run/udev c'est pour pouvoir classer les disques par tag dans Grafana. Pour InfluxDBv2 aucune idée, je ne l'utilise pas. Repars d'une installation clean.

Tu as mis les variables d'environnement qui vont de paire avec le montage de volume ? Mon compose pour Telegraf sur mon VPS si ça peut t'aider, et pas eu besoin de décommenter le "/" dans [inputs.disk] : telegraf: image: telegraf container_name: telegraf networks: - net-monitoring # non-root user needed since 1.20.3 user: 1001:998 environment: - HOST_MOUNT_PREFIX=/hostfs - HOST_PROC=/hostfs/proc - HOST_ETC=/hostfs/etc - HOST_SYS=/hostfs/sys - HOST_VAR=/hostfs/var - HOST_RUN=/hostfs/run volumes: # config - /opt/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # disks input - /etc:/hostfs/etc:ro - /proc:/hostfs/proc:ro - /sys:/hostfs/sys:ro - /var:/hostfs/var:ro - /run:/hostfs/run:ro - /:/hostfs:ro # docker socket mounting - /var/run/docker.sock:/var/run/docker.sock:ro # additionnal MIBs - /var/lib/snmp/mibs:/usr/share/snmp/mibs:ro - /var/lib/snmp/mibs/ietf:/usr/share/snmp/mibs/ietf:ro - /var/lib/snmp/mibs/iana:/usr/share/snmp/mibs/iana:ro # system mounting - /run/udev:/run/udev:ro labels: - "com.centurylinklabs.watchtower.enable=true" depends_on: - influxdb restart: unless-stopped

Bienvenue parmi nous, au plaisir de t'aider au détour d'un sujet. 🙂

Si c'est un point qui te tient à coeur, pense à regarder si tu trouves des NUC de deuxième main, ce sont des périphériques très performants et qui consomment très peu. Et là dessus tu n'auras aucun problème pour installer un adaptateur USB3-RJ45 2.5Gb/s.

Bienvenue parmi nous, ton 207+ peut toujours faire l'affaire pour du bête stockage, la valeur à la revente serait de toute façon quasi nulle. 😉

Il ne faut pas se contenter d'autoriser le protocole SMBv1 en tant que protocole minimum, il faut aussi activer l'option "Activer l'authentification NTLMv1". Et normalement, quand tu tentes d'accéder à un partage, tu dois préciser l'IP ou le nom Netbios du périphérique ainsi que le nom du dossier partagé voulu : \\192.168.1.xxx\stockage pour un dossier partagé nommé stockage.

Le token c'est l'accès à l'API que tu as dû créer au début du tutoriel. Mais si ça fonctionne d'une façon ou l'autre, ce n'est pas la cause, sinon ça ne marcherait pas quelque soit la méthode utilisée. A quoi ressemble ta tâche DSM ?

@MilesTEG1 L'option de nommage du bridge, c'est le nom de l'interface adhoc créée sur le NAS (172.x.0.1), pas le nom du réseau. Ca évite de se taper un nom d'interface généré aléatoirement. @oracle7 Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères.

@oracle7 Ah oui en effet j'ajouterai la précision, mon nom de réseau était bien plus court, je n'aurais pas imaginé. Et les messages d'erreur sont flous au possible.

Ce sont deux sous-réseaux privés liés à ta machine. Ils n'ont aucune raison de se causer entre eux, hormis par l'intermédiaire du NAT sur les hôtes respectifs, aucune raison qu'il y ait donc des problèmes de routage.

@kroumi Première chose à faire, c'est vérifier que ton NAS est accessible depuis l'extérieur, pour ça tu peux utiliser : https://www.yougetsignal.com/tools/open-ports/ Tu dois ouvrir les ports 443 et 80 au monde entier durant le test. Moi, quand je fais le test sur ton nom de domaine, ça me dit que les ports 443 et 80 sont fermés. Or, vu les règles que tu as testées, ça doit être OK pour le NAS, donc recrée les règles de NAT sur ta box, il y a probablement un bug de ce côté-là. Où est hébergée ta zone DNS publique ? PS : Tu peux vérifier l'état de renouvellement et l'historique d'un ou de plusieurs certificats pour un nom de domaine via ce site : https://crt.sh/?q=nasunivers.fr&deduplicate=y

Là en l'état je ne pourrai pas t'aider plus. Je n'ai pas assez de temps libre pour me lancer dans une révision de mon monitoring malheureusement. Si tu arrives à résoudre ton problème n'hésite pas à partager la solution.

C'est énorme 60s de timeout déjà, passer à 10s au lieu de 5s aurait dû suffire si ton réseau n'est pas défectueux. Pour les collections, ce sont tes uniques messages d'erreur ? Ça me semble léger. Tu es bien en log level debug ?

Tu as mis cb de secondes en timeout dans l'input SNMP pour le NAS ?

@oracle7 Je n'ai jamais touché au SNMPv3, vu que je reste sur du polling local je n'en ai jamais vraiment vu l'utilité. Cela dit à première vue ça me semble, sûrement faussement, facile d'accès. et dans le fichier telegraf.conf : # ## SNMPv3 authentication and encryption options. # ## # ## Security Name. # # sec_name = "myuser" # ## Authentication protocol; one of "MD5", "SHA", or "". # # auth_protocol = "MD5" # ## Authentication password. # # auth_password = "pass" # ## Security Level; one of "noAuthNoPriv", "authNoPriv", or "authPriv". # # sec_level = "authNoPriv" # ## Context Name. # # context_name = "" # ## Privacy protocol used for encrypted messages; one of "DES", "AES" or "". # # priv_protocol = "" # ## Privacy password used for encrypted messages. # # priv_password = "" Pour les champs qui n'apparaissent pas dans DSM : https://www.webnms.com/simulator/help/sim_network/netsim_conf_snmpv3.html Si j'en crois cette page, les options dans sec_level définissent l'utilisation ou non des deux autres champs : authentification et niveau de confidentialité. Pour le context_name, l'article ci-avant en parle aussi mais c'est moins clair. Ah, et SNMPv3 utilise a priori le port 10161 au lieu de 161, en tenir compte pour le réglage de ton pare-feu, si tu as verrouillé l'accès depuis Docker (mais je pense que tu aurais eu une connexion refusée plutôt qu'un timeout en ce cas). Désolé, tu as sûrement déjà dû tester tout ça, vu que je viens de trouver ça en faisant une recherche rapide. Mais j'ai pas mieux à offrir 😄 Ah si peut-être, cet issue sur le Github de Telegraf : https://github.com/influxdata/telegraf/issues/3655

Salut @TuringFan Tu peux utiliser le même certificat oui. De souvenir acme permet de déployer le certificat sur plusieurs NAS, d'autant plus s'ils sont reliés par VPN. Mais si tu décidais d'avoir un deuxième certificat pour le même nom de domaine, ça marcherait tout aussi bien. SI ton registrar c'est OVH alors tu peux créer plusieurs dynhost. Du coup tu règles le DDNS du NAS distant de la même manière que le NAS local. Tu peux chiffrer côté client, c'est une option de la sauvegarde. Cela dit si tu utiliser un FQDN sous certificat pour ton NAS distant, pour moi le trafic est naturellement chiffré. Je pense que cette option est utile si tu n'as pas un certificat valide sur ton NAS de destination. A voir avec les experts @maxou56 @PiwiLAbruti Pour ta dernière question je ne sais pas je n'utilise pas Surveillance Station. 🙂

Si tu désactives (disable) le service (pas de lancement au démarrage) et que tu le lances manuellement une fois l'OS booté, ça marche bien ? Pour désactiver : sudo systemctl disable media-greg-DonneesPartagees.mount Pour lancer manuellement : sudo systemctl start media-greg-DonneesPartagees.mount

Non il faut désactiver SMBv1 Tu laisses de 2 à 3, ou 3 seulement. Il faut regarder dans /lib/systemd/system si tu as bien des services qui ont ce nom-là.

Bizarre, tu as bien activé SMB3 sur ton NAS ?

Google ça marche aussi. Ou www.perdu.com Concernant les règles d'accès, ce que je veux dire c'est qu'autant tout laisser dans Authelia plutôt que de mettre des règles dans Nginx ET dans Authelia. Si tu enlèves dashy.ndd.ovh de ton fichier de conf, ça revient à faire ce que tu veux, seuls les accès locaux et vpn seront autorisés (ton premier bloc de règles).

@MilesTEG1 Merci pour la remarque, j'avais màj mon fichier mais oublié de màj le tuto, c'est réparé. 🙂 Oui en yaml : tiré de yaml.org directement. Une site vers lequel tu renvoies l'utilisateur au cas où le proxy inversé n'aurait nulle part vers où renvoyer derrière, ou si tu demandes authelia.ndd.tld par exemple. Je ne pense pas que ça ait d'importance, Authelia doit savoir quel domaine il est sensé protéger, il ne peut pas protéger plusieurs domaines simultanément (tu pourrais avoir plusieurs ndd qui servent ton réseau). Pour ta question concernant les accès locaux, oui tu peux désactiver authelia via le fichier conf de SWAG et ajouter des règles dans nginx, mais est-ce que traiter indifféremment les entrées de proxy pour LAN uniquement ou LAN/WAN et se contenter d'ajouter simplement un bloc de rules dans Authelia n'est pas plus simple ? Moi je trouve que si.