Mic13710

C'est bien la toute première fois que j'entends parler de cette soit disant obsolescence programmée sur un NAS Synology. Etes-vous sûr de ce que vous dites ? Quels sont les symptômes ? N'est-ce pas plutôt la concrétisation du proverbe : "qui veut tuer son chien dit qu'il est malade" ? Pour moi, votre affirmation est invraisemblable. Avez-vous au moins fait les tests, en particulier celui de la CM ? https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly Etes-vous sûr que votre bloc alimentation est OK ? Sinon, si vos disques sont encore bons et n'ont pas été "bricolés" sur un PC, il n'y a aucune raison pour qu'ils ne soient pas migrables. Ce sont les disques qui importent, pas le NAS d'origine. Néanmoins, vous perdrez au passage le bénéfice du BTRFS que procure le 216+ car vos disques sont en EXT4.

Ravivez votre sujet car il est sans doute passé aux oubliettes (en fond de tableau) et que plus personne n'y portera attention.

Comme quoi mieux vaut un qui sait que dix qui cherchent. Je n'avais pas remarqué cette subtilité pourtant si évidente. Merci Fenrir. Je viens d'exporter le certificat et malheureusement ça n'a pas résolu mon problème. J'ai essayé en désactivant puis réactivant le certificat DST Root CA X3, toujours pareil. J'ai essayé de charger le certificat de mon domaine, ça ne change rien. En parallèle, je n'ai aucun problème avec mon smartphone ou celui de ma femme. Il y a juste cette tablette qui fait de la résistance. Il y a manifestement autre chose qui bloque mais je ne vois pas quoi. Edit : Cette tablette fonctionnait bien à l'époque où j'utilisais les certificats startcom. Ce n'est que depuis LE que le problème est apparu, donc clairement à cause du certificat.

Sur ce forum, comme sur beaucoup d'autres, il y a une rubrique dédiée à la présentation. En général, on commence par là. Certains y sont sensibles . RIAD0 ? vous n'avez peur de rien ! Pour la migration, il existe un tuto Synology.: https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_migrate_between_Synology_NAS_DSM_5_0_and_later

C'est un peu le problème. Même si les disques sont extractibles à chaud, il est préférable de le faire à froid. Cependant, il n'est pas sûr avec un volume dégradé et presque en panne que le NAS arrive à redémarrer. D'où le choix pas évident. Il est peut-être préférable de le faire à chaud et si ça ne prend pas, redémarrez le NAS.

C'est aussi un peu le problème. Dans l'aide Android pour installer un nouveau certificat il est dit : Android accepte les certificats X.509 encodés au format DER et enregistrés dans des fichiers .crt ou .cer. J'arrive bien a avoir un .crt en exportant le certificat à partir de Firefox mais c'est celui complet avec mon nom de domaine et donc limité dans le temps. Sais-tu où on peut récupérer le certificat intermédiaire dans ces formats de fichiers ? Car sur le site LE le lien https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt n'est qu'un fichier texte.

La reconstruction signifie que vous supprimez votre volume et que vous le recréez. Les données sont donc perdues. Faite d'abord une sauvegarde de la configuration ce qui vous facilitera la tâche pour la mise en place des paramètres principaux. Vous pouvez tenter de remonter l'ancien disque. Après tout vous ne risquez plus rien. Cependant, vous aurez forcément des erreurs de parité du fait que le disque a été sorti de la grappe. Le gestionnaire devrait vous le dire et au mieux vous proposer une réparation. Si c'est le cas, le disque devra en partie être reconstruit ce qui suppose d'aller récupérer une partie des données sur le disque 2 ..... qui est en panne. Ça ne coute rien d'essayer.

Malheureusement, il semble bien que votre disque 2 soit tombé en panne pendant la reconstruction. Le disque 1 n'étant toujours pas intégré à la grappe (noté comme initialisé), vous n'avez pas de disque de protection. Il est même fort possible qu'une partie de vos données ne soit plus accessible. Il est important de savoir qu'une augmentation de volume n'est pas une opération bénigne. Du fait des déplacement massifs des données, tous les disques sont mis à contribution. Si l'un d'eux est fatigué, il y a des risques qui tombe en panne à ce moment là. Ceci dit, dans le cas présent ces déplacements auraient dû être relativement faibles car il n'y avait pas d'ajout de disque mais un simple remplacement pour lequel l'augmentation ne pouvait se faire qu'avec le 4To. Cependant, le remontage du RAID sur un disque nécessite de récupérer les données sur les autres disques ce qui bien entendu les fait travailler plus que d'habitude, au moins en lecture. Si vous avez lu le tuto que vous donnez en lien, Synology recommande avant cette opération de mettre à jour les sauvegardes. C'est justement pour pallier ce genre de dysfonctionnement qui est finalement assez fréquent, surtout avec des disques 3To dont la fiabilité est souvent mise en défaut sur nos NAS. Dans votre cas, je vous conseille vivement si ce n'est déjà fait de faire la mise à jour des sauvegardes, et de reconstruire votre volume. Vous pouvez tenter la vérification proposée mais uniquement après avoir fait vos sauvegardes.

Ce que vous avez est tout à fait normal. En fait, vous avez remplacé un disque de 2To par un 4To. Ce disque étant plus petit que le plus gros des disques (6To), le SHR n'a pas pu prendre en compte une augmentation de volume mais seulement le remplacement d'un disque défaillant. Il a donc reconstruit le RAID de manière identique et n'a utilisé que 2To sur votre 4To. Votre SHR fonctionne en ce moment comme s'il avait 2x6To + 2x2To soit 10To de stockage avec une protection de 6To. Comme la totalité du stockage disponible est utilisée entre le NAS et le LUN, le bouton gérer est grisé. Si vous vouliez augmenter votre stockage, il aurait fallu remplacer votre 2 To par un 6To minimum.

Merci Fenrir pour ta réponse. Les applis sont contrôlées uniquement à partir des autorités de certification incluses dans Android. Impossible de passer outre si le certificat présenté n'est pas supporté. Je sais qu'on peut rajouter des certificats mais ceux de LE ne sont valables que 90 jours et même moins avec les renouvellements automatiques. Je ne voudrais pas avoir à le faire à chaque fois et surtout à me retrouver hors de chez avec un certif périmé qui m'empêcherait de me connecter. J'ai vu qu'on peut aussi rajouter des certificats CA mais je crois comprendre qu'ils ne sont pas toujours utilisés par les applications. Peut-être que les DS le font, je n'en sais rien. A ce propos, je ne sais pas où je peux trouver celui de LE (le fameux ISRG Root X1) ni comment l'inclure dans Android. J'ai testé mon domaine avec ssllabs (non sans avoir désactivé le pare feu) et à priori je ne vois rien qui cloche. Le niveau général est noté A. Le certificat additionnel LE X3 est bien fourni et il est noté comme délivré par DST Root CA X3. Dans le path des certificats, mon nom de domaine ainsi que le LE X3 sont bien envoyé par le serveur, celui de DST Root CA X3 par contre est noté "in trust store". Dois-je comprendre qu'il n'est pas fourni par le serveur, et est-ce que dans ce cas c'est le client qui, en recevant le LE X3, va rechercher l’émetteur, en l’occurrence DST Root CA X3 ? Enfin dans le "Handshake simulation" Android 4.4.2 est bien validé. A noter que nulle part il n'est fait mention de la certification ISRG Root X1 propre à LE. Ça voudrait dire à priori que LE ne l'utilise pas (pour l'instant) et de le rajouter à la liste ne résoudrait pas mon problème de connexion. Bref, j'ai du mal à comprendre pourquoi ça bloque.

Comme l'autre, soit deux volumes distincts, c'est plus prudent.

Je confirme. Tout dépend effectivement de la manière dont a été construit le SHR. Il faut nous en dire plus sur la chronologie des opérations. Et sur ce forum comme pour beaucoup d'autres on aime bien que les nouveaux arrivants passent par la case présentation avant de poster.

Il y a effectivement un soucis de reconnaissance du certificat du routeur ER-X, mais il suffit de mettre une exception pour s'y connecter. Ce n'est pas un problème en soit dans la mesure ou on ne s'y connecte pas tous les jours. Je ne m'y connecte pas de l'extérieur mais uniquement à partir du LAN. C'était plus gênant pour mes Rasp, d'où mon passage par le reverse proxy.

Je vous confirme aussi que vous ne pourrez pas monter vos disques sur un NAS monobaie pour les lire. Pour la migration, je ne peux pas confirmer que ça marchera. J'ai seulement dit que je ne vois pas de raison pour que ça ne puisse pas se faire. Si vous voulez une réponse précise pour votre cas particulier, le mieux c'est de poser la question au support.

Le RAID n'a jamais été et ne sera jamais une sauvegarde ! Tout ce que vous ajoutez supprimez vérolez ou corrompez volontairement ou pas est aussi ajouté supprimé vérolé corrompu sur l'autre disque. Le RAID n'est qu'un mode de stockage qui permet la continuité de service. en cas de panne d'un disque Il n'empêche nullement de mettre en place une vrai sauvegarde périodique ce que je vous conseille vivement de faire.

C'est bien ce que j'avais pensé comprendre mais j'ai préféré demandé. Il est normal que le NAS bippe puisque votre RAID est dégradé. Si votre NAS a fonctionné avec un seul disque, vous avez effectivement créé des erreurs de parité, d'où la situation que vous rencontrez quel que soit le montage des disques. Il faut donc formater le disque en défaut puis le remonter pour lancer une reconstruction du RAID.

J'accède tout simplement directement au routeur sans passer par le reverse proxy. Comme il est indiqué dans mon tuto, j'ai seulement un enregistrement A pour l'adresse routeur.mondomaine qui renvoie simplement vers l'IP du routeur. Je ne passe donc pas par le certificat du NAS car, comme vous l'avez remarqué, ça ne peut pas fonctionner pour les raisons évoquées par Fenrir.

Je ne comprends pas bien. Avant de rallumer le NAS avez-vous remonté le disque que vous aviez retiré ? Que dit le gestionnaire de stockage ?

Je ne sais pas si la migration que vous envisagez est possible mais je ne vois pas de raison pour que ça ne soit pas possible si vous remontez vos disques dans le même ordre. Pour la version de DSM, il faut surtout que la version du nas de destination soit au moins égale au DSM du nas source. Petite rectification en passant : si vous pensez que vos disques sont en basic, vous faites erreur. Les seuls "vrai" disques basic sur les NAS Synology sont exclusivement sur les modèles monobaie. Pour les autres, tous les disques sans exception sont en RAID monodisque ou multidisque. Pour pouvoir les lire, vous devrez toujours passer par une distri Linux et charger mdadm et lvm2. Voir ce lien.

Bonjour le forum, Je me bats depuis 2 ou 3 jours pour tenter de faire fonctionner mes applications DS sur une ancienne tablette Samsung sous Android 4.4 et je n'y arrive pas car le certificat Let's Encrypt n'est pas reconnu. J'ai le message : "Le certificat SSL du DiskStation n'est pas fiable. blablabla....", un appui sur le bouton OK et ça ne va pas plus loin. Impossible d'outre passer le blocage (je crois que ce n'est pas autorisé sous Android). De ce que j'ai compris des Certificats Let's Encrypt c'est qu'ils sont signés à la fois par Let's Encrypt (ISRG Root X1) et par IdenTrust (DST Root CA X3) afin qu'ils puissent être reconnus par la majorité des navigateurs car Let's Encrypt est trop récent pour être inclus dans les navigateurs plus anciens (mon cas). Il se trouve que DST Root CA X3 est inclus dans Android depuis la 2.3.6. J'ai vérifié et il est bien inclus et activé dans ma tablette. Et donc pourquoi ce refus de mon certificat ? Mystère. Comme il y a deux certificats intermédiaires distincts chez Let's Encrypt, un pour ISRG Root X1 et un autre co-signé par IdenTrust, je me demande si mon certificat inclus réellement la signature d'IdenTrust. Seulement voilà, je ne sais pas où et comment je peux le vérifier. Quand je consulte mon certificat sur le site https://crt.sh il n'est nulle part fait mention d'IdenTrust. Normal ? Pas normal ? Je ne sais pas. Quelqu'un a-t'il réussi à résoudre ce problème d'authentification ?

Et peut-être que la caméra n'est tout simplement pas utilisable avec SS. ONVIF ne garantie pas que SS puisse communiquer avec la caméra, et ce n'est pas parce que l'appli propriétaire fonctionne que pour autant elle peut fonctionner avec SS. Plutôt que d'acheter une caméra au hasard pour se rendre compte par la suite qu'elle ne peut pas fonctionner, il serait plus prudent de consulter la liste des compatibilités. Ca réduit très fortement les risques d'avoir fait un achat pour rien.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Je ne peux rien dire à ce propos. J'ai installé le serveur sous DSM5.2, mais il est possible que depuis DSM6 la configuration ait changé. Il est tout de même plus logique de trouver le répertoire sous l'utilisateur, mais si c'est fait autrement c'est que Synology a pensé que c'était mieux ainsi. Il est possible aussi que ce soit un simple paramètre à régler, je ne sais pas car je n'ai pas cherché. L'essentiel c'est que vous sachiez où il se trouve et c'était la question de départ.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

sudo mdadm ..... C'est ce dont je parlais dans mon premier post.