Mic13710

Groupe ou storage pool c'est la même chose. Si vous êtes français, pourquoi ne pas mettre DSM en français, ce serait plus simple pour comprendre de quoi on parle. Donc, un groupe c'est un ensemble de disques qui peut être constitué de 1 à plusieurs disques. Un groupe de plusieurs disques est obligatoirement en RAID. Sur un groupe, on peut monter un ou plusieurs volumes. Dans le cas présent on passe par deux groupes et deux volumes pour faire le transfert des données vers un groupe définitif constitué de 5 disques. Ce que je propose depuis le début et que je répète une dernière fois, c'est d'utiliser un nouveau disque pour créer un nouveau groupe sur lequel vous mettez un nouveau volume. Sur ce volume vous faites vos sauvegardes. Vous sortez vos anciens disques, mettez les 4 nouveaux restants que vous mettez dans un groupe (différent bien évidemment de celui sur lequel vous avez fait vos sauvegardes). Sur ce groupe vous montez un nouveau volume et sur ce volume vous restaurez vos sauvegardes. La suite je l'ai expliquée plus haut. Maintenant, si vous voulez suivre des vidéos qui expliquent des choses qui ne sont pas du tout adaptées à votre cas, faites. Ce sont vos NAS, ce sont vos données. Oui, vous pouvez monter vos vieux disques issus d'un 410J qui date de 2010 sur un 1522+ qui date de 2022. Vous l'avez fait. Seulement, il y a un énorme gouffre entre les deux NAS et en faisant cela vous importez les limitations du 410J dans le 1522+. C'est comme si vous preniez une carrosserie de Ferrari et que vous y montiez un moteur de clio. Ca va marcher, mais.... Vous ne pourrez pas faire des volumes de plus de 16To car c'est une limitation d'un groupe créé avec un 410J et donc vous devrez créer plusieurs volumes pour pouvoir utiliser la totalité du stockage. Pour vos 5 x 10.9To, cela ferait 3 volumes. Pensez-vous que ce soit ce que vous cherchez ? A vous maintenant de choisir entre la clio ou la ferrari.

Non car si vous faites ça, vous ne ferez qu'augmenter le groupe 2 alors que le but c'est de transférer les données du groupe 2 vers le groupe 1. Vous montez un nouveau groupe et un nouveau volume sur le disque 5 sur lequel vous faites vos sauvegardes hyperbackup. Vous conservez le disque avec vos sauvegardes dans le NAS. Vous sortez les 4 disques anciens (mais vous les conservez sous le coude dans le même ordre pour pouvoir vous en servir si besoin). Vous installez vos 4 nouveaux disques sur lesquels vous créez un groupe (qui devrait être le 1) et un volume. Vous restaurez vos sauvegardes du groupe 2 vers le groupe 1. Quand tout est restauré, vous supprimer le groupe 2 et vous associez le disque au groupe 1 pour augmenter sa capacité.

Pour la faire courte, le transfert des disques du 413 vers le 916 a transféré les limitations du groupe. Entre autres choses, la limite de volume à 16To. Le seul moyen de vous en sortir c'est de sauvegarder toutes vos données, de supprimer le groupe et le reconstruire. Je dirais même plus qu'il serait bon d'en profiter pour redémarrer de 0 avec formatage des disques pour que la partition système puisse être recréé à 7.9To au lieu des 2.2To des anciennes versions.

Pour ton adresse nas.ndd.ovh, c'est soit le fichier .htaccess qui fait la conversion vers https, soit c'est le cache de ton navigateur qui récupère la dernière adresse correspondante. Si tu as vidé ton cache et en l'absence de fichier de conversion, il est normal qu'une url qui ne précise pas le protocole prenne http par défaut. Si le ping est lancé à partir du WAN, c'est normal d'avoir l'IP publique comme résultat. Si le ping est lancé côté LAN et à condition bien entendu que ton serveur DNS local ainsi que le reverse proxy soient paramétrés correctement, c'est l'IP du NAS qui doit être retournée. Si ce n'est pas le cas, c'est que tu as un problème de résolution.

La double authentification c'est très bien, à condition que l'horloge du NAS soit synchronisée et d'avoir les bons outils pour la gérer sereinement (gestionnaire de mot de passe, applis OTP et clé sauvegardée). Si les conditions sont réunis, il ne faut pas hésiter à s'en servir. Mais en principe, sauf si l'accès n'est pas sécurisé, il ne faut pas l'appliquer sur des comptes utilisateurs sinon ça devient vite ingérable. Sur des comptes administrateurs directs (j'entends par là les comptes qui servent à l'administration du NAS), c'est un point sécuritaire qu'il ne faut pas négliger.

Peut-être qu'un petit bonjour serait une bonne entrée en matière pour un premier message sur ce forum. Bref. Je n'utilise pas Secure Sign In. Pour recevoir un email, il faut qu'une adresse mail soit paramétrée dans le service de notification et que vous ayez reçu un mail d'essai pour confirmer que les envois fonctionne. Si vous n'avez plus accès au NAS, le seul moyen c'est de faire un reset mode 1 pour réinitialiser le compte admin. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t1

Que les disques ne soient pas dans la liste peut être la cause. Un NAS est assez capricieux et il y a des incompatibilités avec certains disques, hdd ou ssd. Ce n'est pas parce que les vôtres ont fonctionné un jour qu'ils fonctionneront toujours. Et vous ne pourrez jamais savoir s'ils sont compatibles car Synology ne mettra plus à jour la liste actuelle pour un NAS vieux de 10 ans. Regardez toutefois si vos disques sont acceptés sur des NAS plus récents. Ce n'est pas une garantie, mais ça pourrait donner une idée d'une possible compatibilité avec votre modèle si c'est le cas pour d'autres NAS de la marque. Si votre groupe est en RAID1 ou SHR avec protection des données, pas besoin de sauvegarde pour remplacer des disques. Du moins pour l'opération car une sauvegarde est indispensable en cas de problème, tant en fonctionnement que lors des travaux ponctuels sur le groupe. Bref, tout le temps. Il suffit de remplacer les disques l'un après l'autre, réparation du groupe qui reconstruit le RAID et le groupe augmente une fois le deuxième disque associé au groupe.

Les noms d'hôtes acceptés dans le reverse proxy ne sont que des noms pleins. Vous ne pouvez pas indiquer un service ou un port dans l'url. ndd/photo n'est pas accepté. ndd:port non plus. Le but du reverse proxy c'est de diriger un ndd vers un service. Pour photo station, c'est effectivement avec un ndd/photo qu'on peut joindre l'application. Il n'y a pas besoin de reverse proxy pour ça puisque l'url conduit directement au service. Je sais qu'il y a une astuce pour y parvenir avec un ndd dédié (photo.ndd) et le reverse proxy mais comme ce n'est plus d'actualité avec DSM7.x et Synology Photo, je n'ai plus le souvenir de la manière de procéder. Peut-être avec un .htaccess mais pas sûr.

Tu n'aurais pas une règle du parefeu qui bloque les us ?

Un groupe de stockage n'est pas dégradé avec un secteur endommagé. Le disque a certainement géré le problème en attribuant un secteur de réserve. Si le groupe est dégradé, le gestionnaire devrait vous proposer de le réparer. Si ça fonctionne avec les hdd, de toute évidence ce sont les ssd qui ont un problème. Est-ce qu'ils sont dans la liste des disques approuvés pour votre NAS (dont on ne connait pas le modèle) ? Si l'intérêt pour vous de monter des ssd est de gagner en vitesse, avec un réseau Gb vous pouvez oublier les gains en performance, ils sont quasi nuls. Ce sera le réseau qui coincera. En plus, indépendamment du prix, les ssd ont une fiabilité moindre par rapport aux hdd.

Il semblerait que ce soit cette url qui n'a pas fonctionné. C'est un JSON qui permet de récupérer les liens pour les api et dérouler la suite du script. Tu as ensuite accumulé les time out, le script n'a pas pu aller plus loin et s'est arrêté après plusieurs tentatives. Le site était peut-être indisponible au moment de ta demande. Attends demain pour voir si ça a évolué.

Est-ce que ça fonctionne avec les HDD ? Si oui, ce sont les ssd qui ont un problème, sinon, c'est le NAS qui a un pet' au casque. Vous pouvez faire un test de la carte mère : https://kb.synology.com/fr-fr/DSM/tutorial/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly

Je ne suis pas utilisateur de quickconnect mais il me semble que tout peut se faire sans ouverture de port, y compris les sauvegardes. Il faut seulement que les NAS distants soient des synology qui ont chacun leur propre ID quickconnect. Si ce n'est pas le cas ou que vous souhaitez utiliser les ports, voici la liste synology avec les protocoles : https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Les deux HDD sont aussi impactés ? Etrange. Avez-vous essayé un reset mode 2 qui permet la réinstallation de DSM ? https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t2 Pour le formatage, il n'y a rien de particulier à faire. Un simple formatage rapide sur un PC suffit, le but étant de détruire la partition système (la première) pour que DSM parte sur une nouvelle installation. Si vous voulez un formatage plus profond, vous trouverez facilement des outils sous linux en interfaces graphiques et/ou en lignes de commandes. Gparted par exemple devrait répondre à votre besoin.

Que tout ceci me semble compliqué ! Je ne comprends pas ce que vient faire l'upnp là dedans ni à quoi servent ces redirections côté LAN. Si vous utilisez uniquement quickconnect, vous n'avez pas besoin d'ouverture et de redirection de ports. Je pense qu'il suffit de rétablir la connexion de quickconnect et c'est tout. Néanmoins, la freebox pro comporte certaines lacunes en matière de paramétrage contrairement à la révolution et il se peut qu'il faille creuser un peu plus et vous orienter vers une configuration plus classique qui sera de toute manière bien meilleure que quickconnect.

Si je comprends bien, les deux ssd ont fonctionné dans le NAS (votre premier message). Si ça ne fonctionne plus maintenant après avoir remis les disques dans le NAS, ce n'est pas de l'incompatibilité mais seulement un problème de disque. Pour le vérifier, ne montez qu'un seul disque et faite une installation de DSM. Si ça fonctionne avec un disque et pas avec l'autre, vous aurez trouvé le coupable.

MariaDB est bien dans /var/packages/MariaDB10/ Pour la suite, je ne peux guère vous aider je n'utilise pas.

Pour la vérification de la date, c'est la date d'expiration qui est recherchée dans la fonction certificat_check() avec openssl x509 -checkend $(( (90 - RENEWAL_CYCLE) * 86400 ))Vu comment c'est construit, checkend va lire la fin de validité du certificat (en secondes) et s'il reste moins que le renewal_cycle, un nouveau certificat est demandé. Avec le certificat actuel sur 90 jours, le renewal_cycle à 61 donne en réalité un certificat renouvelé tous les 29 jours. Donc, tu as déjà un script qui tient compte de la nouvelle donne. Néanmoins, la validité du certificat LE va diminuer ces prochains mois et ça va coincer dans le bocal. Il va falloir corriger le script pour qu'il couvre les validités réduites. Edit : Désolé, j'ai mal interprété checkend. 90 = durée standard d’un certificat Let's Encrypt (pour le moment) RENEWAL_CYCLE=61 Donc : 90 - 61 = 29 jours => Le script vérifie que le certificat est encore valide dans 29 jours. C'est toujours sur une durée de 60 jours avant renouvellement. Donc, c'est bien ce que je disais, il faut passer RENEWAL_CYCLE à 31 pour que le renouvellement intervienne après 30 jours. Ceci n'est que temporaire car le problème va se poser à nouveau lorsque la durée de validité du certificat va diminuer. Cette manière de gérer la durée du certificat sur une durée fixe de 90 jours est extrêmement bizarre de toute façon. Aussi, pourquoi ne pas laisser acme.sh gérer les validités ou plus simplement utiliser les infos de ndd.conf qui donne Le_NextRenewTime et Le_NextRenewTimeStr qui sont directement écrit par acme.sh ? J'aurais bien un correctif à te proposer mais ce n'est pas le lieu pour le faire (hors sujet)

Tu as raison. Je n'étais pas connecté lorsque j'ai essayé de télécharger. Mia culpa.

D'autant que le script n'est plus disponible au téléchargement.... Déjà tu peux modifier RENEWAL_CYCLE=30 Le certificat LE est encore de 90 jours. Le renouvellement raccourci est là pour préparer l'obligation d'arriver à des certificats d'une durée de validité de 45 (ou 47 je ne sais plus) jours en 2027. Tu peux consulter le calendrier des étapes et des durées sur le net. Acme a choisi dès maintenant un délai de 30 jours pour laisser du temps (15 jours à terme) pour que le renouvellement puisse se faire avant l'échéance au moment de l'application d'une validité raccourcie. Donc mieux vaut anticiper aussi dans le script.

Pas à ma connaissance. Quand ça change, c'est un peu la surprise. Il faut suivre le github. C'est comme le passage du nom du certificat en base 64 dont la transition m'a posé quelques problèmes à l'époque sans que comprenne réellement pourquoi. Le script s'évertuait à le passer en base 64 mais j'étais obligé de le remettre en clair pour le renouvellement. Et puis c'est rentré dans l'ordre à la mise à jour suivante. Tu as noté que maintenant les certificats sont renouvelés tous les 30 jours depuis décembre ?

Ca confirme ce que j'ai déjà dit : le script python est obsolète tout comme ce tuto. Le nom du certificat en base64 est inscrit dans les fichiers de conf depuis au moins 3 ans. Le script lui le lit en clair. Je ne saurais trop vous recommander de laisser tomber ce tuto qui n'est plus maintenu depuis des années et vous tourner vers la solution de base dont je vous ai donné le lien ou vers la solution docker qui est dans la section des tutoriels. Cette dernière reprends le même fonctionnement que la solution de base dont il s'inspire.

Je viens de jeter un oeil sur le script python et effectivement, il n'est pas à jour puisqu'il recherche des valeurs qui ont été renommées comme vu plus haut : for ligne in LeNddConf : if "Le_NextRenewTime" in ligne : nextrenewtime = re.findall('\'(.*?)\'', ligne)[0] if "Le_NextRenewTimeStr" in ligne : nextrenewtimestr = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_Username" in ligne : SAVED_SYNO_Username = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_Password" in ligne : SAVED_SYNO_Password = re.findall('\'(.*?)\'', ligne)[0] if "SAVED_SYNO_DID" in ligne : SAVED_SYNO_DID = re.findall('\'(.*?)\'', ligne)[0] Ceci explique pourquoi ça ne fonctionne pas. Vous pouvez modifier le script pour les nouvelles dénominations mais cela ne garantit pas que le reste fonctionne encore.

Comme je l'ai dit, je n'utilise pas ce tuto. J'ai cru comprendre au fil de cette discussion que le script python n'est plus applicable avec les dernières versions de DSM, mais je n'en suis pas sûr. De toute manière, je n'ai jamais été convaincu de son utilité. De plus, je crois que le script en question n'est plus maintenu depuis des mois/années. J'ai un NAS dont je m'occupe qui n'est pas sous docker et pour lequel je passe par la procédure de base : GitHubSynology NAS GuideA pure Unix shell script ACME client for SSL / TLS certificate automation - acmesh-official/acme.shCa fonctionne très bien. Si votre NAS est compatible docker (ce que vous ne dites pas), alors je vous conseille de vous tourner vers le tuto correspondant.

Bonjour et bienvenue sur ce forum.