Classement

Il n'y a plus de mise à jour automatique des versions mineures de DSM pour les modèles des séries ´16 à ´19 depuis DSM 7.2. Elles ne peuvent donc être faites que manuellement.

Bon finalement j'ai pu tout récupérer depuis linux et j'ai retrouvé le fichier .pat...sur le NAS...quel boulet (j'étais jeune et bête)...C'est la version modifié du 1635 pour tourner sur un CS406, si qq1 est intéréssé un jour (avant que je le reperde)...il fait 153Mo

Comme je bosse sur un projet utilisant Tailscale, ton sujet m'a interpellé en ai discuté avec la LLM qui me donne la main et voilà ce qu'il en ai ressorti en espérant que cela puisse t'éclairer : Pourquoi NextDNS “voit” 4 IP mais seulement 3 Apple🔍 Ce qui se passe réellementApple Private Relay : intercepte une partie des requêtes DNS + HTTP(S) les fait sortir via des egress Apple (Cloudflare / Akamai / Apple) masque l’IP source réelle parfois split le trafic : une partie passe par le DNS “système” une autre ne passe PAS par ton NextDNS 👉 Résultat : NextDNS voit : des IP Apple relay parfois plusieurs IP pour un seul device Le message NextDNS est volontairement flou car Apple ne documente pas précisément le mapping 🧠 Conclusion ➡️ Les 4 IP ≠ 4 machines ➡️ Ce sont des sorties Apple Relay, pas des hôtes réels Pourquoi les NAS Synology n’apparaissent PASEt là on arrive au point clé 👇 ⚠️ Les NAS n’utilisent probablement PAS NextDNSCas les plus fréquents sur DSM : ❌ Le NAS utilise : le DNS du LAN ou /etc/resolv.conf généré par DSM ou un fallback IPv6 ❌ Le trafic DNS du NAS : passe en dehors de Tailscale ou passe par Tailscale mais ne fait aucune requête DNS observable (cache, peu d’activité) ❌ Tailscale DNS ≠ garantie d’usage réel 🧠 Point fondamental ➡️ Tailscale DNS est déclaratif, pas coercitif Réponse à la question centrale 👉 Réponse honnête : NON, il n’en a aucune certitudeEt actuellement : ❌ Apple = couverture partielle (Private Relay) ❌ NAS = probablement hors périmètre ❌ Tailscale = aucune visibilité par device 🧭 Recommandations claires (par ordre de maturité)🟢 OPTION 1 — Vérification factuelle (indispensable)Sur chaque NAS Synology : cat /etc/resolv.conf Puis : nslookup google.com ➡️ Vérifier vers quel DNS ça sort réellement 🟢 OPTION 2 — Désactiver Apple Private Relay (si objectif = contrôle DNS)Sur Apple : iCloud → Private Relay → OFF 💬 Sans ça : aucun DNS central ne peut être fiable NextDNS, Pi-hole, AdGuard = tous aveugles partiellement 🟡 OPTION 3 — Forcer NextDNS par appareil (recommandé)Au lieu de “DNS global Tailscale” : Installer NextDNS client : sur macOS sur iOS sur DSM (possible via script / container sidecar) ➡️ Là, NextDNS tagge chaque appareil ➡️ Plus de doute ➡️ Plus de mapping fantôme 🟡 OPTION 4 — Architecture propre (niveau Rahan 🧠) Tailscale : transport DNS : local-first Apple Private Relay : OFF sur machines de confiance 👉 Sinon : Il empile des couches qui s’aveuglent mutuellement 🧩 Synthèse ultra-courte à transmettre à ton ami

Bonjour, c'est corrigé. merci

Aucun souci sur le mien, ni sur mes App docker

Çà pourrait aussi être mon diagnostic, à voir ce que veut dire une alimentation "compatible", même si elle date de 2024

C'est toujours difficile d'apporter des réponses à ce genre de problème. Ca peut être l'alimentation (alimente un disque mais pas les 4), un disque HS qui bloque le boot, le système corrompu. Si le NAS ne démarre pas avec les 4 disques, j'aurais tendance à dire que c'est l'alimentation qui est défaillante.

Je n’ai jamais eu de souci avec les paquets que j’utilise.

Je ne travaille pas avec des mac... je suis allergique 😄

Bonjour @Loïc Segnon Question beaucoup trop vaste. Il faut partir de ton budget et de tes besoins. Sois plus précis et on pourra te conseiller.

Bonjour, Il faudrait déjà t'assurer que les nouveaux routeurs fonctionnent bien et qu'il sont à jour, en te connectant directement dessus depuis un PC/Mac (port LAN) ou via l'application du fabricant. Ton routeur principal devra aussi disposer de la dernière version du firmware. Une fois cette vérification faite et l'éventuelle mise a jour réalisée, réinitialise les : bouton reset à actionner avec une épingle ou un trombone pendant au moins 5 secondes je crois. Ceci fait tu pourras entamer l'ajout de chaque MR2200AC en mesh, de préférence en te plaçant proche du rt2600ac pour garantir qu'il soit bien à portée du routeur ou en filaire (Synology avait normalement fiabilisé l'extension du mesh via un backhaul filaire).

C'est assez logique... Sinon ça boucle dans le vide.

Je déterre le sujet si jamais c'est toujours d'actualité. Je suis entrain de passer mes backups offsite d'Azur vers Wasabi storage S3 et ils semblent proposer cette fonctionnalité de rétention : https://docs.wasabi.com/docs/how-to-enable-and-test-compliance-on-a-bucket-immutability aucune idée si celà peut être compatible avec Hyper Backup par contre...

Et plus précisément : Est-ce que le paquet SMB Service est installé ? https://www.synology.com/fr-fr/dsm/packages/SMBService

merci pour la réponse. C'est fait et nous avons eu la réponse. Effectivement il s'agit d'un bug sur la 7.3 (depuis la 1ere version). Un correctif est prévu (quand ?). En attendant pour résoudre le problème nous avons découvert qu'il ne fallait pas utiliser la planification de synchronisation de l'AD sur le NAS. C'est ce que nous a confirmé Syno. Dommage que ce genre de bug majeur ne soit listé quelque part, avec le contournement possible. Cela éviterait 2 jours de travail avant de comprendre et de trouver nous-mêmes la solution.

Il faut espérer que les constructeurs de disques dur mettent de la mauvaise volonté pendant quelles mois/ Années. cela serait bienvenu de leur part. Un peu comme le passage des disques CMR et SMR dans une même gamme de disques.