Mic13710

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.

Je confirme, md2

C'est très simple : Synology n'utilise pas le RAID4, ni en classique ni en shr. Le SHR n'a rien de propriétaire. Ce n'est ni plus ni moins qu'un mdadm (RAID classique) avec une couche lvm2. Edit : Si vous avez un SHR, vous pouvez en activant le SSH passer cette commande en mode terminal : parted --list Vous verrez que vos disques sont soit en RAID1 soit en RAID5 selon leur nombre et leurs tailles. Il ne sera pas fait mention de SHR.

Raid 4 ? C'est de RAID 5 dont vous voulez parler. Le SHR fonctionne exactement comme le RAID1 lorsqu'il y a 2 disques et comme le RAID5 au delà de 2 disques. Le SHR2 fonctionne exactement comme le RAID6. Ce qui différencie le SHR du RAID classique c'est la possibilité d'utiliser des disques de tailles différentes avec pour seule contrainte lors de l'augmentation de volume d'utiliser un disque de taille au moins équivalente au disque le plus grand de la grappe. Quand je dis que ça fonctionne exactement comme un RAID classique, c'est bien le cas. Simplement le SHR "saucissonne" les disques de manière à pouvoir utiliser au mieux les espaces présents. Par exemple, si on monte une grappe avec 2 disques de 3To et 2 disques de 4To, le SHR va d'abord créer un RAID5 classique en utilisant 3To sur chaque disque soit 9To de stockage et va ensuite créer un RAID1 avec les 1To restants des 4To. Au final, le SHR sera composé d'un RAID5 de 9To réparti sur 4 disques et d'un RAID1 de 1To réparti sur 2 disques, soit une capacité totale de 10To. Si par la suite on remplace un 3To par un 4To, le SHR va reconstruire le RAID1 pour le transformer en RAID5 sur les 3 espaces de 1To des 3 disques de 4To augmentant ainsi le stockage de 1To supplémentaire. Si enfin on remplace le dernier 3To par un 4To, le groupe de 1To sera encore augmenté d 1To. Le SHR sera alors constitué d'un RAID5 de 4x3To et d'un RAID5 de 4x1To soit 12To. Avec un RAID classique, la construction se serait arrêté au RAID5 ne donnant qu'un stockage de 9To et aurait laissé de côté les 1To des 4To. L'augmentation n'aurait pu se faire qu'après avoir remplacé les 2 disques de 3To. Cette augmentation se serait faite sur le seul RAID5 de 9To qui passerait alors à 12To et non pas par la création d'un nouveau RAID5 comme c'est le cas pour le SHR. En résumé, le SHR permet de contrôler plusieurs RAID classiques à l'intérieur d'une même grappe.

Les mail sont stockés dans le répertoire .Maildir de chaque utilisateur. En recopiant à l'identique les comptes d'un NAS vers l'autre, vous recopierez aussi les mails.

Les solutions fonctionnent mais il faut accéder au NAS en SSH avec le compte admin (et non root) et faire précéder les commandes d'un "sudo ". Un tuto de Gaëtan Cambier ici.

Par contre je m'inquièterais du stockage dispo. 29Go c'est vraiment pas beaucoup. Va falloir faire du ménage ou envisager une augmentation du volume (remplacement des deux disques par des plus gros)

Euh, pas vraiment. C'est le disque 1 qui a un problème, c'est donc à partir des données du 2 que le SHR sera reconstruit. Mais il faut en effet être sûr qu'il s'agit bien d'un SHR avec protection des données.

@YSG Hors sujet. Ouvrez un sujet pour soumettre votre problème.

Ne serait-ce pas un problème d'embrochage du disque qui aurait bougé durant le transport ?

Du RAID0 pour de la sauvegarde et en plus avec des 3To dont on connait la propension à tomber en panne ? Si ça ne dérange personne, pourquoi pas. Après tout on peut toujours sauter dans le vide sans parachute. Pour moi, une sauvegarde doit avant tout être fiable. Je ne crois pas que le RAID0 soit un modèle de fiabilité. C'est quoi au juste un RAID Basic ?

Pas plus performant mais plus efficace. Un peu de lecture Je ne sais pas si la barrette du 416Play est amovible ou soudée. Par contre, vous ne pouvez pas y mettre n'importe quoi. Le mieux serait de poser spécifiquement la question sur un fil dans le forum matériel dédié. Avec du SHR sur les 4 disques, vous perdrez 2To pour la protection des données. Avec 4 disques en basic vous aurez la capacité totale mais il faudra remplir chaque disque séparément (4 volumes) et répartir finement les données pour pouvoir tout stocker.

Je ne saurais dire si c'est un problème de stockage, mais il se peut très bien qu'un des disques soit en fin de vie. Que disent les tests smart étendus ? Il est certain qu'une nouvelle installation est à privilégier. Si vous pouvez le faire, n'hésitez pas, d'autant que vous pourrez alors passer au BTRFS au lieu du EXT4. Toutefois, je vous recommanderais de remplacer votre 3To par un 4To ne serait-ce que pour éviter la multiplication des RAID par le SHR. Mais pas seulement. Les 3To sont très souvent à l'origine de pannes de disques sur les NAS Synology. Le choix du RAID0 pour y stocker temporairement vos données n'est pas du tout judicieux. Surtout sur des disques qui ont probablement un nombre important d'heures de fonctionnement. Si un disque tombe en panne, vous perdez tout. Vous pouvez choisir le JBOD qui est un peu moins contraignant que le RAID0. Le mieux serait de faire 4 disques en basic (ou SHR sans protection de données) car si un disque tombe en panne il reste encore les données des disques sains. Mais si je ne m'abuse, vos anciens disques ont un total de 7.5To. Est-ce suffisant pour tout y mettre ?

Il manque effectivement 1To sur le 3To. Seulement 2To sont exploités sur ce disque : un espace de 1495Go pour un premier RAID et un autre de 500Go pour le deuxième. Il manque donc 1To non utilisé. A cette reconstruction en gras, seulement 2To ont été exploités . Il n'y a pas eu d'augmentation du stockage car le SHR a considéré ce disque comme un remplacement d'un disque en panne et non comme une augmentation de volume qui est impossible puisque le disque est de taille inférieure aux disques les plus gros (4To). Au remplacement du 4To, le SHR n'a pas tenu compte de l'espace restant, ce qui explique l'écart constaté. Comme vous ne pouvez pas sortir le 3To pour le réintroduire dans la grappe (il ne sera pas accepté car de taille inférieure aux disques existants mais seulement comme le remplacement d'un disque de 2To), la seule solution qui éviterait une réinstallation complète serait de remplacer le 3To par un 4To.

Ca n'a rien à voir avec les limitations des volumes qui elles sont inhérentes à l'installation initiale, pas à la version de DSM.

Une migration d'un 410J vers un 416Play, des remplacements de disques à tout va, ça explique peut-être pourquoi il y a des écarts. Les disques issus de migrations conservent les paramètres et les limitations du NAS d'origine. Cela peut avoir des conséquences surprenantes lors des modifications suivantes avec des résultats en retrait par rapport à ce qui est attendu. Lorsque le pas est trop important ce qui est le cas ici, plutôt que de faire une migration il est fortement conseillé de repartir sur une nouvelle installation. Moi-même par exemple j'ai migré les disques de mon 710 sur le 214 et aussi surprenant soit-il la limitation se situe sur la taille du volume que je ne peux pas augmenter. Si je veux le faire, je ne peux pas avec la manière traditionnelle. Je suis obligé de changer les disques et de refaire une installation neuve. Pourtant le 214+ est capable de gérer des volumes bien plus importants que celui de 4To que j'ai actuellement.