PiwiLAbruti

Dans quelle section sont créées ces règles de filtrage ? (affichée en haut à droite, non visible sur la capture d'éran)

Il suffit que les nouveaux disques demandent plus de courant au démarrage pour mettre en défaut l'alimentation, d'où le voyant orange et la perte de visibilité dans Synology Assistant.

Ça pourrait venir de l'alimentation qui faiblit et qui ne parvient pas à alimenter le disque inséré. Essaye avec une autre alimentation ayant les mêmes caractéristiques.

Préfixe la commande avec sudo pour inclure tous les chemins : sudo df -h

Ok, donc tu as un serveur DIY en plus de ton Synology.

Dans le cas d'un groupe de stockage NVMe, DSM n'est pas répliqué sur tous les lecteurs du NAS ? (bande RAID1 à la fois sur les SSD et les HDD ?)

Il y a une autre solution consistant à créer une tache de synchronisation dans l'application Drive. Ainsi, la cible peut être synchronisée dans le stockage local de l'appareil Android. Étant synchronisé, le contenu est toujours disponible hors-ligne.

Je n'avais même pas vu que Synology avait fait une page d'aide à ce sujet : https://kb.synology.com/fr-fr/DSM/tutorial/How_should_I_receive_external_email_messages_via_MailPlus

Dans un premier temps, utilise directement les serveurs AdGuard plutôt que l'Orange Pi : IPv4 : 94.140.14.14 et 94.140.15.15 IPv6 : 2a10:50c0::ad1:ff et 2a10:50c0::ad2:ff Une fois le problème d'accès web résolu, tu pourras réutiliser l'Orange Pi.

Je n'ai aucun souci pour résoudre nas.ndd.ovh quelque soit le résolveur utilisé : > nslookup nas.ndd.ovh Réponse ne faisant pas autorité : Nom : ndd.ovh Address: a.b.c.d Aliases: nas.ndd.ovh Donc il doit déjà y avoir un problème avec tonAdGuard sur Orange Pi pour que la résolution ne fonctionne pas chez toi. Par contre, depuis un navigateur j'ai systématiquement le message L’adresse IP du serveur nas.ndd.ovh est introuvable. Et en regardant de plus près, la connexion n'est pas chiffrée alors que l'URL utilise bien le protocole HTTPS. Plus précisément, le NAS ne renvoie aucun certificat au client pour sécuriser la connexion. Il y a donc un problème dans ta configuration (reverse proxy, des certificats, redirection HTTP>HTTPS, Web Station, …). En entrant http://nas.ndd.ovh:443, j'arrive sur la page de WebStation :

Je n'ai pas compris. Le problème n'a rien à voir avec adblock dans Firefox, ce n'est pas ça qui fait échouer la commande nslookup. Concentre-toi plutôt sur la résolution de nas.ndd.ovh sur différents résolveurs. Si aucun ne parvient à résoudre ce nom, c'est qu'il y a un problème dans le zone DNS. SI tous parviennent à le résoudre sauf ton AdGuard, c'est qu'il y a un problème au niveau du résolveur sur ton Orange Pi. Si tu es complètement perdu, donne-moi ton nom de domaine en MP.

Les résolutions DNS montrent que le serveur DNS utilisé par défaut pour les résolutions est 192.168.1.27. Est-ce que le nom nas.ndd.ovh est bien défini dans la zone DNS correspondante ? Car le serveur DNS répond qu'il ne le trouve pas.

Ou mieux, déclarer une nouvelle zone chezmoi.nomdedomaine.fr chez OVH (depuis le bouton Actions sur la zone principale > Ajouter un sous-domaine), ou dans DNS Server (il faudra également une zone locale sur ce dernier).

On est pas loin de la théorie du complot 🤔 Les résolutions DNS semblent poser problème. Donc le seul test que tu dois faire est avec la commande nslookup (ou Resolve-DnsName via PowerShell) en précisant le serveur avec lequel tu souhaites effectuer la résolution. Laisse tranquille IPv6 en le laissant tel qu'il est configuré par défaut (actif).

Y a-t-il un routeur configuré dans Panneau de configuration > Accès externe > Configuration du routeur ?

Je n'ai pas de réponse certaine à cette question, mais je le déconseillerais sous peine de casser le RAID et les volumes associés. Synology ne donne aucune indication à ce sujet : https://kb.synology.com/fr-fr/DSM/help/DSM/StorageManager/storage_pool_change_raid_type

Ça dépend si tu as une sauvegarde de tes données en cas de problème. Et au passage, un onduleur est obligatoire pour éviter les interruption d'alimentation pendant cette opération critique.

Je ne sais pas si c'est toujours d'actualité, mais ça compromettrai les chances de succès d'un tunnel chez HE : https://dev.freebox.fr/bugs/task/12749#comment179146

Les logs indiquent des connexions infructueuses à DSM, ce qui provoque des blocages. Il faudrait déjà identifier d'où proviennent ces connexions. L'adresse IP WAN peut être vue si l'adresse IP publique est utilisée en local et que le loopback est activé sur le routeur/box. Il me semble que c'est le cas si tu utilises le DDNS Synology en local.

Ce n'est que de l'affichage, il suffit que le client mail le propose.

Je n'utilise pas OwnTracks, mais il y a un bref tutoriel pour les NAS Synology sur le site officiel : https://owntracks.org/booklet/clients/recorder/#recorder-on-synology As-tu essayé de l'appliquer ?

Dès la première ligne du script, il semble y avoir un caractère étrange après /bin/bash Édite le script avec Notepad++ pour vérifier l'encodage ANSI et les sauts de ligne UNIX (LF).

Une connexion sécurisée est une connexion chiffrée. Dans le cas présent, l'URL affiche le port tcp/5000 qui établit une communication non-chiffrée (http://*.synology.me:5000). Pour établir une connexion chiffrée, il faut utiliser le port tcp/5001 : https://*.synology.me:5001

Je n'ai jamais eu ce cas sur des OS autres que ceux de Microsoft. Sur Windows Server notamment, si la machine présente un décalage horaire que plusieurs minutes (ou heures) avant la configuration d'un serveur NTP, l'heure sera progressivement ajustée jusqu'à l'heure réelle (le temps passe plus vite ou moins vite selon le sens du décalage). Il se peut donc que l'heure se corrige également toute seule dans le cas présent, à vérifier.

Vérifie aussi si ta caméra est compatible ONVIF.