RAHAN-31

Merci du partage @Pascalou59

Elle est si mauvaise que cela cette idée ? 🤔

Merci de ton retour et... bon courage !😬

Salut @Pascalou59 , Je me permets une petite réflexion qui n'est peut-être qu'une fausse piste. Pour l'instant, j'ai l'impression que nous observons trois symptômes simultanément : le commutateur réseau VMM ne s'initialise plus ; le pool de stockage VMM ne s'initialise plus ; la VM Windows 10 n'a plus de connectivité. Avant de chercher une solution, il serait peut-être intéressant d'essayer d'identifier quel est le premier domino qui est tombé, les deux autres pouvant n'être que des conséquences. Peux-tu préciser : Le paquet Virtual Machine Manager démarre-t-il correctement ? Le commutateur virtuel existe-t-il toujours mais reste « Non initialisé », ou a-t-il disparu ? Le pool de stockage VMM est-il toujours présent mais non initialisé, ou complètement absent ? Les fichiers de la VM sont-ils toujours présents sur le volume de données ? Les autres services DSM (SMB, Container Manager, Plex, etc.) fonctionnent-ils normalement ? Si tu es d'accord, je pense qu'il serait également très utile d'examiner les journaux avant toute manipulation. Si les journaux sont trop volumineux pour être publiés sur le forum, je suis tout à fait disposé à les analyser en privé si tu souhaites me les transmettre par messagerie. L'objectif n'est pas de proposer une manipulation supplémentaire, mais d'essayer de remonter jusqu'au premier événement ayant déclenché cette cascade. Cela nous évitera peut-être de corriger un symptôme alors que la cause se situe ailleurs.

Créer un environnement de laboratoire DSM sans exposer le système de production : vos avis ?Au fil de cette discussion, nous avons beaucoup progressé dans la compréhension de l’évolution des partitions système (p1 à 8 Gio) et du comportement actuel de md0. En parallèle, une idée de protocole expérimental a émergé. Avant d’aller plus loin, j’aimerais savoir si cette approche comporte une faille technique que je n’aurais pas identifiée et bénéficier de vos regards critiques avant d’envisager la moindre manipulation. Principe envisagéSur mon DS1621+, mon Storage Pool de production — SPN, constitué de trois MG11 de 22 To et actuellement porté par le Volume 2 — resterait intact. Je créerais en parallèle un Storage Pool Laboratoire — SPL sur deux anciens HDD de 6 To, avec son propre volume séparé, en espérant que DSM ne réattribue pas le Volume1. L’objectif serait de laisser DSM initialiser naturellement ces anciens HDD et y répliquer le système actuellement actif. L'hypothèse est que j'obtiendrai : p1 physiques = 8 Gio md0 logique = ~2,37 Gio filesystem / = ~2,3 GioUne fois la réplication terminée, je vérifierais que le NAS peut démarrer correctement avec le SPL seul. Le NAS serait ensuite arrêté et les trois MG11 de production retirés physiquement, les baies 1/2/3 leur restant réservées. Toutes les expérimentations seraient alors réalisées uniquement sur les anciens HDD et dans les baies 4 -> 6, les disques de production restant hors du NAS. Objectifs techniquesAnalyser en profondeur toute la chaîne système : partitionnement, RAID md0, éventuelles couches propres à DSM et filesystem racine ; Tenter un grow manuel de md0, puis de son filesystem, en CLI ; Observer le comportement de DSM avant et après reboot ; Redémarrer, contrôler l’intégrité du système et tenter ensuite une mise à niveau DSM 7.3 → 7.4 ; Déterminer si cette modification produit un état durablement compatible avec les mécanismes de maintenance et de mise à jour de DSM. L’idée n’est donc pas de modifier directement le système de production, mais de créer sur mon propre NAS un environnement reproductible dans lequel je pourrais observer, comprendre, me tromper et recommencer sans exposer les quatre actifs essentiels actuellement portés par le SPN : les données ; la configuration DSM ; la configuration et l’état des paquets ; leurs interdépendances. Avant d’aller plus loin, j’aimerais recueillir votre avis. Voyez-vous une contre-indication technique à cette approche ? La création du SPL et la réplication du système sur ses HDD peuvent-elles modifier ou fragiliser d’une quelconque manière le système actuellement porté par les MG11 du SPN ? L’hypothèse selon laquelle le SPL pourra ensuite démarrer de manière autonome avec une copie cohérente du md0 historique vous paraît-elle fondée ? Existe-t-il une autre couche ou dépendance DSM susceptible de rendre ce laboratoire non représentatif du système de production ? Enfin, afin de ne pas détourner davantage ce fil consacré à la mise à jour DSM 7.4, pensez-vous préférable d’ouvrir un sujet dédié à cette expérimentation ? Dans l’affirmative, dans quelle section serait-il le plus pertinent de le créer ? L’objectif n’est pas de défendre cette idée à tout prix, bien au contraire. Si cette idée comporte une faiblesse, je préfère largement qu'elle soit identifiée ici avant même la première manipulation. C'est précisément le but de cette réflexion. Merci d’avance pour vos remarques.

Mode vieux con => ON Attention tout de même à ne pas réduire le problème à notre cas relativement favorable p1=8 Gio → md0=2,3 Gio. Le cas de @Mic13710 montre déjà qu'il existe des géométries historiques différentes, celui de @Pascalou59 montre qu'un système peut avoir été modifié hors des chemins prévus par Synology, et il doit exister quantité d'autres héritages issus des migrations, remplacements successifs et configurations RAID/SHR. Depuis notre canapé, le grow paraît presque trivial. Pour Synology, le vrai problème est probablement de déterminer avec une certitude suffisante quand il est sûr de le faire, et surtout quand il ne faut pas le faire. C'est finalement pour cela que la réponse à la question laissée sous le coude à @Pascalou59 m'intéresse davantage que nos spéculations sur le déclencheur : savoir si Synology travaille sur un mécanisme officiel de migration qualifiée de ces anciens md0, ou si le Mode 2 restera définitivement la seule voie supportée.

@Pascalou59 Une dernière réflexion issue de la réponse du support, que je te laisse simplement sous le coude si ton échange avec eux se poursuit. Finalement, au-delà de savoir si 7.4 déclenche ou non le passage de md0 de ~2,37 Gio à ~8 Gio, la question qui conditionne vraiment la stratégie à long terme serait de savoir si Synology prévoit un mécanisme officiel permettant un jour cette migration automatiquement, sans passer par un Mode 2. Car les conséquences sont complètement différentes : Mécanisme prévu ↓ rester en 2,37 Gio peut avoir du sens et attendre sa disponibilité Mécanisme non prévu ↓ autant envisager le Mode 2 au moment où les conditions sont les plus favorablesSi tu juges le moment opportun et que ton ticket est toujours ouvert, voilà la question que je poserais au support : Aucune urgence à la poser : je te la laisse simplement sous le coude si l'occasion se présente. 😉 Rassure-toi : dans la confrérie des « plus malins qui s'en sont mangé les doigts quelques années plus tard », tu es loin d'être seul. 😉 Et vu ce que je viens de découvrir sur mon propre NAS après des années d'évolution DSM… je vais soigneusement éviter de te jeter le premier secteur. 😇

@Mic13710 Tout à fait d'accord. C'est même désormais le test le plus intéressant et le moins intrusif : si @Pascalou59 récupère suffisamment d'espace après son reboot pour lancer normalement 7.4, un relevé df / proc/partitions / mdadm avant et après nous dira directement si l'upgrade constitue le fameux déclencheur. Le Mode 2 ne viendrait qu'ensuite si nécessaire... malheureusement 🤒, on vient de gagner au passage une migration Data mine de rien 🥳 Donc Wait and See la réponse du tech à notre question concernant la préservation du poo/volume Data et/ou celle de son upgrade...

Merci @Pascalou59 pour avoir complété la réponse du support, là c'est beaucoup plus clair ! Leur proposition confirme donc bien que, dans ton cas particulier : p1 physiques = 8 Gio md0 historique = ~2,37 Gio ↓ Mode 2 + réinstallation DSM ↓ partition système = 8 GoEt le fait qu'ils proposent ensuite de restaurer la configuration DSM laisse logiquement penser que le pool et le volume DATA existants sont conservés. Mais c'est justement le dernier point que j'aimerais verrouiller explicitement, car les conséquences ne sont évidemment pas les mêmes entre « réinstaller DSM » et « reconstruire le stockage ». Si ton ticket est toujours ouvert, pourrais-tu leur poser cette dernière question, idéalement en anglais pour éviter toute ambiguïté : Leur réponse permettrait de savoir précisément où se situe la frontière de l'opération. Ton retour concernant Surveillance Station illustre d'ailleurs parfaitement le problème suivant : préserver les DATA ne signifie pas nécessairement préserver l'ensemble de l'environnement applicatif. La configuration DSM, les configurations propres aux paquets et leurs interdépendances constituent également des actifs qu'il faut pouvoir restaurer. Merci encore de nous faire suivre les échanges avec le support.

Salut @Pascalou59 , merci de ton retour, Peux tu poser cette question au technicien si il prend contact avec toi ?

Bon... vos échanges m'ont fait mettre le nez dans les entrailles de mon propre NAS et je viens de découvrir quelque chose qui change pas mal ma perception du problème 😅 Mon DS1621+ a une longue histoire derrière lui : son DSM remonte à l'époque de DSM 4 et de son DS1512+, puis a été mis à jour au fil des années jusqu'à DSM 7.3 aujourd'hui. Je viens parallèlement de terminer une migration complète de mon stockage : mes anciens HDD ont été remplacés par 3 Toshiba MG11 22 To neufs, actuellement constitués en SHR-1 / Btrfs. Malgré le renouvellement complet des HDD, ma partition système est toujours : root@Synology:~# df -h / Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.4G 852M 62% /Jusque-là, je pensais donc simplement avoir hérité de l'ancien partitionnement système de mon installation historique. Sauf qu'en regardant /proc/partitions, surprise : sata1p1 8388608 sata2p1 8388608 sata3p1 8388608 sata1p2 2097152 sata2p2 2097152 sata3p2 2097152 md0 2490176 md1 2097088Les trois HDD neufs possèdent donc déjà chacun une p1 de 8 Gio, alors que md0 reste dimensionné à environ 2,4 Gio. Si j'ai correctement compris la mécanique, ma situation est donc plutôt : HDD1 p1 = 8 Gio ─┐ HDD2 p1 = 8 Gio ─┼──> md0 RAID1 ≈ 2,4 Gio ──> filesystem / ≈ 2,3 Gio HDD3 p1 = 8 Gio ─┘Autrement dit, le nouveau partitionnement physique existe déjà sur tous les HDD. C'est md0, puis son filesystem, qui n'exploitent pas encore l'espace disponible dans les p1. Et c'est là que j'aurais une question pour @Mic13710, @PiwiLAbruti ou quiconque aurait déjà rencontré ce cas : DSM possède-t-il un mécanisme prévu/supporté permettant de faire croître md0 lorsque TOUS ses membres p1 sont déjà passés à 8 Gio ? Et surtout, si oui, quel est le déclencheur du grow ? Une mise à niveau majeure de DSM ? Une réparation/reconstruction particulière ? Le remplacement du dernier HDD portant l'ancien partitionnement ? Une opération interne de DSM ? Une intervention du support Synology ? Je sais que Linux permet techniquement d'agir sur le RAID puis le filesystem avec mdadm/resize2fs, mais ce n'est volontairement pas la question : je cherche à savoir si DSM possède lui-même un mécanisme prévu pour effectuer cette transition, sans bidouille manuelle sur sa partition système. et @Pascalou59 ton cas pourrait justement être intéressant pour essayer de comprendre cette mécanique. Ton dernier relevé donne actuellement : /dev/system-root 2.3G 1.9G 359M 84% /On connaît par ailleurs ta configuration : DS723+, 32 Go de RAM, 2 SSD M.2 de 500 Go en cache et 2 IronWolf 8 To en RAID1. Avant de chercher, comme le suggère @Mic13710, quels dossiers pourraient être allégés afin de récupérer suffisamment d'espace pour tenter normalement la mise à niveau DSM 7.4, pourrais-tu nous donner : sudo cat /proc/partitions sudo cat /proc/mdstat sudo mdadm --detail /dev/md0Si la dernière commande ne trouve pas /dev/md0, poste simplement son retour : ton DSM présentant actuellement / sous /dev/system-root, /proc/mdstat nous permettra d'abord d'identifier précisément l'array concerné. Ce qui m'intéresse surtout est de savoir si les partitions système p1 de tes deux IronWolf sont encore à ~2,5 Gio ou si elles sont déjà passées à 8 Gio. Si elles sont toutes les deux à 8 Gio alors que ton filesystem système reste à 2,3 Gio, nous serions potentiellement dans la même situation malgré nos architectures DATA différentes : RAID1 chez toi, SHR-1 chez moi. On pourrait alors, dans un second temps, chercher proprement ce qui peut être allégé sans risque dans tes 1,9 Gio occupés, avec l'objectif de permettre à l'upgrade 7.4 que tu souhaites déjà réaliser de démarrer. Et si elle passe, refaire les mêmes relevés après l'upgrade permettrait simplement d'observer si DSM laisse la partition système logique à ~2,3 Gio ou s'il sait exploiter les p1 de 8 Gio déjà présentes.

C'est ce que j'appelle une très mauvaise nouvelle… surtout lorsqu'on sort tout juste d'une migration complète d'un Storage Pool d'environ 15 To, dont l'installation DSM remonte à l'origine à DSM 4 et a été mise à jour au fil des années ! Je me retrouve donc avec des HDD neufs et une architecture de stockage entièrement renouvelée, mais avec un DSM qui conserve son ancienne partition système md0 de 2,3 Go au lieu du partitionnement actuel d'environ 7,9 Go. Certes, parler d'un DSM immédiatement « condamné » serait excessif : DSM 7.3 me convient parfaitement et 7.4 semble encore pouvoir fonctionner sur une ancienne md0. Mais le problème est ailleurs : je viens de pérenniser le stockage sans réellement pérenniser le système. À terme, si cette petite partition finit par empêcher les futures mises à niveau de DSM, ce n'est pas tant DSM lui-même qui m'inquiète que tout l'écosystème qui repose dessus : Plex, Container Manager, Home Assistant, HACS et les autres paquets et services. Ce sont des actifs vivants, qui évoluent rapidement avec leurs dépendances, API, codecs, formats, clients, protocoles, etc. Les figer aujourd'hui reviendrait progressivement à condamner l'ensemble du système, alors même que le matériel et les nouveaux disques pourraient parfaitement continuer à rendre service pendant des années. Ce qui me gêne surtout est que cette limitation est totalement invisible lors d'une migration. DSM connaît pourtant la taille et la génération de sa partition système. Il me semblerait donc particulièrement utile que l'assistant affiche, lorsqu'il détecte l'ancien partitionnement, un avertissement du genre : « Votre système utilise un ancien schéma de partitionnement système. La migration vers de nouveaux disques conservera cette limitation. Une installation fraîche de DSM est nécessaire pour bénéficier du nouveau partitionnement système. » Une telle information avant de lancer une migration de plusieurs téraoctets pourrait complètement modifier la stratégie choisie par l'administrateur. Dans mon cas, si j'avais connu cette contrainte avant de commencer, j'aurais au minimum étudié une migration différente permettant de repartir sur un DSM fraîchement partitionné, quitte à accepter une procédure plus lourde. C'est donc une prise de conscience assez douloureuse après le temps et l'argent investis : la migration des données est réussie, les nouveaux HDD sont là, mais je découvre après coup que j'ai également transporté sur eux une dette technique vieille de plusieurs générations de DSM. Sur ce point, je trouve vraiment que la communication de Synology est plus que perfectible. Un simple avertissement au bon moment aurait permis de faire un choix éclairé.

<Slt @KeizerSauze , je vais te répondre que sur la partie que je pense maîtriser... donc hors univers Apple et Mullvad VPN. Lorsque tu es sur ton UI web de TailScale [TS], l'ensemble de tes machines doivent être sur le même Tailnet et donc être toutes "connected" et administrable dans le même parc machines. Tu ne dois pas toucher à l'exit Node qui ne doit te servir qu'au cas ou tu voudrais que cela soit le device sur lequel tu l'actives qui devient la porte d'entrée pour internet. Normal que tu ne puisses pas l'activer/désactiver sur le NAS puisque sans son internet tu ne peux plus le voir. ^^ Donc chaque device mobile peuvent activer l'exit Node mais pas les autres. Pour ce qui est de la visualisation de ton fichier... fait un essai hors TS, repère bien les répertoires depart/arrivée et refait la même chose sous TS tu dois obtenir le même résultat. Pour aller plus loin dans la vérification : - Pour vérifier réellement l’usage DNS sur le NAS, il faut faire un test direct (ex. cat /etc/resolv.conf puis nslookup vers un domaine) pour voir vers quel serveur DNS il résout réellement. - Installer un client NextDNS par appareil (ou configurer explicitement le resolver sur DSM) donne une meilleure traçabilité que de s’appuyer uniquement sur Tailscale DNS global. Ce qui compte, c'est le chemin pour y arriver... pas l'arrivée... quoique ;-)

👉 Réponse courte : OUI… mais seulement sous conditions strictes. 👉 Réponse honnête : ça ne résout PAS Apple Private Relay, et ça ne garantit pas 100 % de couverture sans coercition réseau. On déroule proprement. 🧠 Principe général : DNS au routeur = point de centralisationConfigurer NextDNS au routeur (DNS classique ou DoH) signifie : Tous les clients qui respectent le DNS du LAN et qui ne contournent pas le DNS 👉 passeront par NextDNS 📌 C’est une centralisation, pas une garantie absolue. ✅ Ce que ça couvre VRAIMENT🟢 Appareils “normaux”NAS Synology PC / Linux VM / containers IoT Services système classiques ➡️ OUI, ils passeront par NextDNS si : DHCP du routeur = DNS unique pas de DNS hardcodé pas de DoH local actif 👉 Dans ce cas, NextDNS verra clairement le trafic (IP = routeur ou subnet). 🟡 NAS Synology (cas précis DSM)DSM respecte le DNS LAN mais : peut avoir fallback IPv6 peut cacher l’origine (cache agressif) ne “tagge” pas l’appareil dans NextDNS 👉 Résultat : trafic visible mais non attribuable finement par machine ✔️ Couverture fonctionnelle ❌ Traçabilité par device ❌ Ce que ça ne résout PAS🔴 Apple Private Relay (point bloquant)Apple Private Relay : court-circuite DNS + HTTPS sort via Apple (Cloudflare / Akamai) ignore totalement : DNS du routeur DoH du routeur DNS Tailscale Pi-hole NextDNS 👉 AUCUNE config routeur ne peut forcer ça. 📌 Donc : Apple + Private Relay = angle mort DNS même avec NextDNS au routeur ➡️ Obligation : Private Relay OFF ou accepter une visibilité partielle 🔴 DoH / DoQ côté clientSi un appareil : utilise DoH intégré (Firefox, Chrome, Apple) ou un client NextDNS local ou un resolver embarqué 👉 il bypass le routeur Sauf si tu fais… 🧱 Le seul moyen de “forcer” réellement (niveau expert)🔥 DNS coercitif au routeurBloquer tout DNS sortant UDP/TCP 53 DoH (443 vers resolvers connus) Autoriser uniquement : routeur → NextDNS (DoH) 👉 Là : tout DNS est capturé tout contournement échoue ⚠️ MAIS : Apple Private Relay casse quand même le modèle certaines apps refusent de fonctionner maintenance plus lourde ➡️ Approche “souveraineté”, pas grand public 🧭 Interaction avec TailscaleImportant à se rappeler : Tailscale DNS : annonce un DNS ne force rien DNS routeur : centralise LAN n’affecte pas le trafic encapsulé Private Relay 👉 Les deux sont complémentaires, mais aucun n’est coercitif seul. 🧩 Synthèse 🧠 Recommandation finaleSi l’objectif est savoir qui fait quoi : ❌ Private Relay ✅ NextDNS par appareil 🟡 DNS routeur en complément Si l’objectif est juste filtrer globalement : ✅ NextDNS au routeur 🤷 accepter les angles morts Apple

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