Classement

Bonjour Pour ma part cela fonctionne chez moi par contre je ne suis pas sur d'avoir la même configuration que vous. Je m'explique: J'ai un certificat dédié à ça et il est gère par active backup, ma version est là 2.7.1-13235 Et le Windows est 10 build 19045 J'ai aussi la sauvegarde d'un serveur Linux et cela fonctionne bien aussi

Refonte du tutoriel pour la V6, amélioration du fichier compose et mise à jour des impressions d'écran.

J'ai trouvé 🙂 Le paramètre ADMIN_TOKEN doit être inséré sans les doubles $

La liste n'est plus mise à jour car il s'agit d'un ancien modèle. Et les disques ne sont plus commercialisés pour bon nombre d'entre eux. Les deskstar sont des Hitachi. Ce sont en général de très bons disques mais depuis leur rachat par WD, j'aurais tendance à penser que les gammes s'harmonisent.... Les anciens NAS sont assez tolérants sur les disques, beaucoup plus en tout cas que les derniers modèles. Je ne peux que vous suggérer de vous tourner vers des disques qui sont compatibles avec des NAS séries J ou standards plus récents que le votre. Et surtout, ne prendre que des disques en techno CMR (pas de SMR !).

Pour que ça fonctionne avec un nom de domaine au travers de wireguard ou de n'importe quel autre VPN, il faut qu'il y ait une résolution locale de l'URL et un reverse proxy pour diriger la requête vers le service demandé, ici votre application docker. Sans cela, c'est l'adresse que vous utilisez localement qu'il faut prendre. Vérifiez aussi que Wireguard autorise toutes les IP à traverser le VPN (allowedIPs = 0.0.0.0/0). Il faut que le parefeu du NAS autorise les IPs de Wireguard (10.x.x.x/xx). Mais pas en https je présume, que ce soit localement ou à distance sauf à faire une exception. Ce qui signifie que le certificat n'est pas sollicité et/ou qu'il ne couvre pas le ndd. Pour cela, il faut mettre une règle dans le reverse proxy qui dirige https://xxxx.myds.me port 51821 vers localhost et le port de votre application docker. Ce serait d'ailleurs plus simple d'utiliser le port 443 dans le reverse proxy avec un nom de domaine dédié, par exemple : https://votreapplication/xxx.myds.me port 443 vers localhost et le port de votre application. Je vous conseille d'aller faire un tour dans la section des tutoriels et de regarder le tuto sur le serveur DNS et celui sur le reverse proxy.

Hello, j'ai aussi fait la migration il y a quelques semaines et ça s'est très bien passé. Je vais essayer de trouver le temps de mettre à jour le tutoriel, je devrais retrouver des disponibilités à partir de fin juin...

Et pourtant ce n'est pas ça qui coinçait mais WGUI_ENDPOINT_ADDRESS. Pour le coup j'ai fait une recherche pointilleuse dans le fichier de config afin de repérer et de corriger tous les wiregard qui pouvaient traîner. WireGuard (avec un u...) est vraiment une Rolls comparé à OpenVPN !

Le problème c'est qu'à la prochaine panne, ce sera fatal. Je vous recommande vivement de le faire le plus rapidement possible. Avec la 100ohm, le courant absorbé par le circuit d'horloge est beaucoup trop important pour le besoin réel du circuit. Il surchauffe et risque de griller. A vous de voir si vous prenez le risque ou si vous jouez la prudence. De toute manière, ce "patch" n'est qu'un bricolage pour maintenir en vie le NAS. Le problème CPU demeure et votre NAS peut tomber en panne à tout moment.

Sans doute, mais cette info n'a pas sa place ici. Elle serait plus adaptée dans ce sujet : On y explique que la résistance de 100ohm est trop faible et doit être augmentée à 300ohm approx.

Si vous passez par une installation à partir de zéro, cad à partir de disques vierges, est-ce que ça bloque ? Je pense que oui, mais comme je l'ai dit, on ne sait jamais. Sinon, je vous ai déjà donné la meilleure idée que j'avais. Je n'ai plus rien en stock, désolé. Il vous reste à trouver toutes les versions dans la liste donnée plus haut pour arriver à la dernière dispo sur le site. Ou bien attendre que le site d'archive reprenne du service.

J'ai 3 PC sous windows. Pas de problème chez moi sur les PC en W11. Dernières sauvegardes effectuées ce matin. Par contre, celui sous W10 que je n'avais pas utilisé depuis 2-3 semaines était noté en attente de mise à jour du client au niveau du serveur. Je viens de faire la mise à jour et ... j'ai le même message "Erreur d'internet.." ! Par trop le temps de lancer des investigations mais c'est peut-être lié à la version de windows. Quelle est celle de tes PC ?

Donc, vous ne savez pas ce qu'est un DDNS sinon vous ne diriez pas cela. Il y a un petit tuto sur ce forum qui vous permettra de comprendre les bases des réseaux :

Pour commencer, il faut corriger une confusion bien trop courante : un certificat NE S'APPLIQUE QUE SUR UN NOM DE DOMAINE ! jamais sur une IP. Si vous voulez un certificat sur votre nom de domaine, il y a plusieurs méthodes : via DSM, la plus simple mais il faudra ouvrir le port 80 au moins pour le renouvellement et relancer le renouvellement manuellement ou à l'aide d'une tâche planifiée la méthode par docker, mais votre NAS n'est pas compatible. la méthode via SSH qui est équivalente à celle via docker et qui utilise le script acme.sh (dépôt Github : https://github.com/acmesh-official/acme.sh). La mise en oeuvre n'est pas très simple mais lorsqu'il est en place, le renouvellement se fait automatiquement. Dans votre deuxième message, vous faites là aussi une erreur. Ce n'est pas l'IP privée qu'il faut renseigner mais l'IP publique de votre box à l'instant de la mise en place du DDNS. Vous pouvez l'obtenir en consultant ce site : https://www.mon-ip.com/ Mais pour pouvoir faire fonctionner le DDNS sur votre NAS avec un NDD OVH, il faut d'abord paramétrer le DynHost dans la zone chez OVH et paramétrer les identifiants de connexion. Vous trouverez tout un tas de tutos sur la toile vous indiquant comment paramétrer le DynHost et l'identifiant de connexion.

Je ne connais pas la beestation, mais à lire les caractéristiques, elle n'a aucune application embarquée comme DSM. Même le cloud ne semble n'être qu'une sauvegarde de cloud externes. Tournez vous vers un NAS, un vrai. Si vous avez fait votre recherche avec le sélectionneur de NAS et que le DS124 est donné pour correspondre à vos besoins, alors pas de soucis. Sachez toutefois qu'il faut prévoir de la marge car lorsqu'on commence avec un NAS, on y trouve des tas de services à lui donner à faire auxquels on avait pas pensé au départ. Aussi choisir un modèle trop juste risque d'engendrer de la frustration. Prévoyez aussi de la marge sur la taille du disque par rapport à vos besoins (un facteur 2 est conseillé). Par ailleurs, sachez que la migration d'un disque issu d'un NAS monodisque ne peut se faire que vers un autre NAS monodisque de la même marque. Il n'y a pas non plus de passerelle pour migrer des disques d'un NAS de marque X vers un NAS de marque Y, chaque constructeur ayant sa gestion propriétaire. Ca n'a rien à voir avec les données qui elles peuvent être migrées de tout support vers tout support.

Le RAID n'est pas du tout prévu pour cet usage et je vous déconseille vivement de mettre en pratique ce que vous envisagez. D'abord, un RAID est un groupe actif et sortir un de ses disques casse le groupe. Celui-ci fonctionne alors en mode dégradé et envoie une alarme qui ne s'arrête que lorsque le groupe est réparé. Et lorsque vous remonterez le disque, ce dernier ne sera pas reconnu puisqu'il aura été éjecté du groupe ce qui conduira à une reconstruction complète pour associer à nouveau le disque (de nombreuses heures). Franchement, adoptez une solution universelle qui consiste à faire des sauvegardes périodiques de vos données. Ce sera beaucoup plus efficace et plus simple en terme de gestion des données. Après, le choix du NAS dépend de ce que vous voulez utiliser comme applications. Si c'est pour consulter et gérer des photos, n'importe quel modèle fera l'affaire. Ce qui peut faire la différence c'est le temps de création des vignettes qui sera plus ou moins long suivant les capacités du NAS. Cela peut prendre plusieurs jours à plusieurs semaines suivant la quantité et la qualité demandée. Il faut surtout évaluer vos besoins présents et futurs et en vous aidant du sélectionneur de NAS dispo sur le site de Synology, vous aurez plusieurs modèles qui vous seront proposés. https://www.synology.com/fr-fr/support/nas_selector Vu que ce sont des vignettes qui s'affichent dans l'application Synology Photos, le modèle de NAS n'a que peu d'impact sur la vitesse d'affichage.

C'est bien ce que j'ai donné comme info dans mon premier message. C'est donc 30 jours avant la date d'expiration ce qui laisse largement le temps de renouveler le certificat, et qui signifie que vous aviez un problème qui bloquait ce renouvellement.

C'est facile : un certificat LE est valide pendant 90 jours. Je vous laisse faire le calcul...

Le renouvellement d'un certificat LE sur un ndd xxx.synology.me se fait automatiquement tous les 2 mois. Le blocage peut avoir plusieurs causes et il est impossible d'en faire le tour sans plus d'informations. Il faudrait commencer par étudier et mettre en pratique le tuto sur la sécurisation de nos NAS. On y parle aussi de la mise en oeuvre du certificat. Peut-être que ça vous permettra de résoudre votre souci de renouvellement.

Pas évident que cela fonctionne car le processus de maj passe aussi par une écriture sur le NAS. Mais qui ne tente rien n'a rien. Au pire, le NAS vous dira s'il ne peut pas.

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.

Oui. Si les plages sont identiques (votre cas), toute requête locale qui peut être résolue localement ne passera pas le VPN. C'est un point important à vérifier lorsqu'on met en place un service VPN : s'assurer que les plages d'IP serveur/client sont différentes. Pour éviter cela, il faut en changer et choisir de préférence des plages autres que 192.168.0.0/24, 192.168.1.0/24, et 192.168.254.0/24 qui sont celles utilisées par défaut par les opérateurs.

Permissions de l'utilisateur à accéder au dossier et autorisation d'utilisation d'hyper backup ?

http:\\192.168.xx.xx:5000 ou bien avec l'IP du VPN http:\\10.x.y.z:5000

Non, vous pouvez très bien avoir à la fois un nom de domaine et quickconnect. Et d'ailleurs, dans la période de transition mieux vaut garder les deux jusqu'au basculement définitif de tous vos clients puisque ceux-ci utilisent quickconnect. C'est bien évidemment important impératif de faire des sauvegardes quel que soit le support de la source. Beaucoup malheureusement oublient ce point crucial pour une bonne gestion des données. Mais lorsqu'on parle d'utilisation professionnelle , il est tout aussi important de garantir la continuité de service à ses clients. C'est ce que procure le RAID1 dans votre cas (ou SHR avec protection des données). Attention à une confusion bien trop courante à propos du RAID : ce n'est pas une sauvegarde ! juste une continuité de service en cas de panne de disque.

Quickconnect n'est clairement pas le moyen de connexion le plus stable, et sûrement pas celui à adopter en milieu professionnel. Il est de loin préférable de passer par un nom de domaine. C'est certes plus compliqué à mettre en oeuvre mais tellement plus efficace que quickconnect en terme de rapidité et de fiabilité qu'il ne faut pas hésiter une seule seconde. Je vous conseille de commencer d'abord par sécuriser votre NAS en suivant le tuto de @.Shad. . Vous y trouverez comment installer un nom de domaine Synology (xxxx.synology.me) qui est le minimum à mettre en place dans votre configuration. J'ai noté dans votre présentation que vous aviez paramétré votre NAS avec 2 groupes, un professionnel et un privé. Je ne pense pas que ce soit la meilleure approche car la perte d'un disque implique la perte de toutes les données qu'il contient. Et lorsqu'on est dans un milieu professionnel, la perte d'exploitation peut s'avérer désastreuse. Il eut été plus judicieux de monter des disques plus gros en RAID (ou SHR avec protection des données) et pourquoi pas, mais ce n'est pas non plus la bonne approche, monter deux volumes sur le groupe unique. Ainsi, la perte d'un disque permet de continuer l'exploitation sur le disque restant en attendant le remplacement du disque défectueux. En ce qui concerne votre problème avec quickconnect, je ne pourrai pas vous aider car je n'utilise pas ce service.

Certains l'ont fait avec des disques USB mais c'est très instable (pas garanti de conserver le numéro d'usbshare ni de le maintenir actif), dock obligatoire (pas d'alimentation via le NAS) et obligation de remonter le lecteur à chaque redémarrage. En tout cas, je ne me lancerai pas dans cette opération plus qu'incertaine. La seule méthode qui fonctionne à 100% c'est d'augmenter la capacité des disques existants. Comment sont montés vos disques, sur un ou deux groupes ?

On peut toujours ajouter un disque USB, mais la vrai question est : pour quoi faire ? De la sauvegarde ? Du stockage supplémentaire ?

Ce mécanisme n'existe pas. A ma connaissance, c'est seulement dispo sur les versions Office 365 et uniquement fonctionnel via le Drive de Microsoft.

Je ne comprends pas cette phrase. Vous devriez lire et surtout intégrer ce petit lexique. Il vous permettra de mieux comprendre comment fonctionne un réseau : Et merci de ne pas citer inutilement le post auquel vous répondez. Ca charge le sujet sans apporter un plus à la compréhension.

C'est un peu la base non ? Ca ne change rien par rapport à ce que vous faisiez sur votre box. Entendons nous bien. Lorsque je parle de DMZ, c'est seulement sur la box que ça se passe, absolument pas sur le nouveau routeur, sinon effectivement c'est open bar sur votre réseau privé ! Donc, DMZ (ou mode bridge si dispo) sur la box (on ne connais toujours pas votre FAI et le modèle de box) et ouverture des ports sur le nouveau routeur.

Et ? Une DMZ ouvre l'ensemble des ports vers l'ip que vous choisissez. Il est donc normal que tout passe puisque c'est son but. C'est ensuite sur votre routeur que les protections doivent être mises en place. Si vous ne voulez pas de DMZ (ce qui serait contre-productif mais pourquoi pas) il faut ouvrir tous les ports dont vous avez besoin pour tous les services qui doivent avoir accès au WAN. Ce n'est pas le meilleur choix car c'est bien au niveau du nouveau routeur que l'ouverture des ports doit être faite.

Ce n'est pas trop le forum sur lequel poser ce genre de question qui concerne l'installation d'un routeur tiers. De plus, votre demande est bien trop vague pour que quiconque puisse y répondre. Sans un minimum d'informations sur votre box, votre fai, le modèle de routeur, les ports utilisés par votre NAS ainsi que les réservations d'IP existantes (sur le NAS ? sur la box ?), impossible de donner suite.

Selon votre version actuelle, il faut procéder par étapes et monter de version en version en suivant le processus indiqué sur le site Synology. Pour votre modèle de NAS, de la première à la dernière version : Le problème c'est que Synology a supprimé les anciennes versions de DSM (dans votre cas jusqu'à la version 6.0.3) et le seul moyen de les récupérer est (était ?) via un site d'archive du web. Malheureusement, le site est inaccessible depuis plusieurs jours et il n'y a aucune information quant à sa réouverture. Sinon, il va vous falloir fouiller la toile à la recherche des différents .pat jusqu'à la 6.0.3. Les versions supérieures sont encore dispos sur le site comme indiqué dans la capture ci-dessus.

Vérifiez les paramètres SMB de votre NAS. Windows 11 n'accepte plus ( à juste titre) SMB1. Je vous conseille d'aller faire un tour dans la section des tutoriels où vous trouverez celui concernant la sécurisation de nos NAS. On y explique entre autres les réglages à effectuer pour SMB.

Ce qui veut dire que le NAS n'est pas accessible quel que soit le protocole. Et les autres voyants LAN et disk ? Plus d'infos sur la led status qui clignote : https://kb.synology.com/fr-fr/DSM/tutorial/What_can_I_do_if_the_STATUS_LED_keeps_flashing_in_orange

Ok, mais est-ce que le NAS va jusqu'au mode ready (voyant status allumé) ?

Merci à tous pour vos retours. En regardant mieux mes logs, j'ai vu que le renouvellement du certificat sur mon NDD Gandi n'a pas été non plus de tout repos. Il a fallu plusieurs jours avant que ça passe. Etrange tout de même que ce soit uniquement sur le NDD OVH que le souci ait perduré jusqu'à extinction du certificat. A la réflexion, je me demande si ça ne serait pas lié à l'évolution de mon réseau vers Unifi et de la "tambouille" que j'ai du mettre en place pour pouvoir utiliser le player freebox sur le LAN. A moins que ce soit un blocage de dns par pihole. Je n'ai pas la réponse. Je pourrais forcer le renouvellement mais je n'ai pas le temps. Je verrai au prochain renouvellement et si ça coince, je ferai des tests plus approfondis.

Vous brulez les étapes. Sortez le disque qui semble HS et essayez de démarrer le NAS avec le disque sain. Si ça fonctionne c'est que le disque est effectivement HS et il faut le remplacer. A réception des nouveaux disques, il suffira d'en monter un dans le NAS et de lancer la reconstruction à partir du gestionnaire de stockage. L'autre disque neuf ... à vous de voir ce que vous en faite.

C'est expliqué dans les notes de versions : Version: 24.0.2-1535 (2025-02-11) Important Notes Starting from this version, if you perform a clean install of the package, the "docker" shared folder will not have the "Hide this shared folder in My Network Places" setting selected by default. As of this version, settings for containers—including ports, volumes, environments, and links—cannot be modified post-creation. To modify the settings, duplicate a desired container and make the change to the newly created one.

Edit: J'ai lancé le renouvellement avec l'instruction dnssleep et ça a marché. docker exec Acme sh -c "acme.sh --issue --force --keylength 4096 -d '<Mon NDD>' -d '*.<Mon NDD>' --dns dns_ovh --dnssleep 300" Suivi d'un lancement de déploiement et c'est reparti. docker exec Acme sh -c "acme.sh --deploy -d '<Mon NDD>' --deploy-hook synology_dsm" Ca ne résout pas le problème mais au moins j'ai un certificat valide. A voir dans 2 mois lors du prochain renouvellement.

Salut, Le dernier renouvellement de mon certificat sur mon nom de domaine chez OVH ne s'est pas fait, et chaque tentative journalière se solde par un échec. Et cela sur mes deux NAS. Par contre, le renouvellement de mon autre nom de domaine chez Gandi s'est fait sans trop de problème sur mes deux NAS (juste un ou deux échecs mais rien d'anormal). Mes API sont correctes puisque les entrée TXT sont bien écrites dans ma zone DNS, mais ça bloque à chaque fois lors de la vérifications des dns publics : [Sun Jun 8 03:25:30 UTC 2025] Let's check each DNS record now. Sleeping for 20 seconds first. [Sun Jun 8 03:25:50 UTC 2025] You can use '--dnssleep' to disable public dns checks. [Sun Jun 8 03:25:50 UTC 2025] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck [Sun Jun 8 03:25:50 UTC 2025] d='<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] aliasDomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] txt='TRms99shC4euqpAUu3pD4YO-Zv8puWhxRgmuuncz1ns' [Sun Jun 8 03:25:50 UTC 2025] d_api='/root/.acme.sh/dnsapi/dns_ovh.sh' [Sun Jun 8 03:25:50 UTC 2025] Checking <Mon NDD> for _acme-challenge.<Mon NDD> [Sun Jun 8 03:25:50 UTC 2025] _c_txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] _c_aliasdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] _c_txt='TRms99shC4euqpAUu3pD4YO-Zv8puWhxRgmuuncz1ns' [Sun Jun 8 03:25:50 UTC 2025] Detecting DNS server first. [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.google' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.alidns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://doh.pub' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] No DOH [Sun Jun 8 03:25:50 UTC 2025] Detecting DNS server first. [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.google' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.alidns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://doh.pub' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] No DOH [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com/dns-query?name=_acme-challenge.<Mon NDD>&type=TXT' [Sun Jun 8 03:25:50 UTC 2025] timeout= [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] Not valid yet, let's wait for 10 seconds then check the next one. [Sun Jun 8 03:25:50 UTC 2025] _p_txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] Purging Cloudflare TXT record for domain _acme-challenge.<Mon NDD> [Sun Jun 8 03:25:50 UTC 2025] POST [Sun Jun 8 03:25:50 UTC 2025] _post_url='https://cloudflare-dns.com/api/v1/purge?domain=_acme-challenge.<Mon NDD>&type=TXT' [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] _ret='6' Toutes les lignes ci-dessus sont répétées pas moins de 160 fois à chaque fois que le script est lancé ! C'est 6000 lignes qui sont enregistrées dans le fichier acme.sh.log qui à ce jour comptabilise 251000 lignes depuis le 01/01/2025 ..... A comparer aux 27000 lignes du fichier de 2024. Bref, il y a comme un souci alors que je n'ai rien modifié, l'image docker ainsi que le script acme.sh sont à jour. J'ai beau chercher, je ne trouve rien dans les logs d'anormal exceptés ces recherches sur les dns publics qui me semblent étranges et que je ne retrouve pas pour les renouvellements précédents. Est-ce que ceux qui sont chez OVH ont pu renouveler leurs certificats ou suis-je le seul dans ce cas ?

Sans les disques je suppose ?

Indépendamment du problème d'alim, je vois que vous avez des WD60EFAX sur votre NAS. Comment sont-ils montés : en RAID (ou SHR) ou en groupes séparés ? Ces disques sont en techno SMR et ne sont plus compatibles avec les NAS. Ils ont d'ailleurs été retirés des listes de compatibilité chez Synology. Un peu de lecture : Ce n'est pas cela qui a pu provoquer votre problème actuel, mais il faut être conscient que vos disques peuvent subir des dysfonctionnements sur la gestion et l'accès aux données.

Y'a pas comme un truc qui cloche ? En l'absence de test des disques, il n'est pas évident de définir la source du problème, mais s'ils tournent comme vous le dites dans votre dernier message, alors il y a de fortes chances pour que ce soit un problème sur le bloc d'alimentation.

A moins d'avoir un minimum de matériel (charge variable, appareil de mesure) il est impossible de tester. Si vous avez la possibilité d'emprunter une alimentation, vous pouvez essayer avec un autre bloc, sinon, il faut commander, en espérant que ce soit ça. Il faudrait avant cela tester les disques dans un dock pour voir s'il n'y en aurait pas un HS. Qu'a donné le test de la CM ?

Oui mais est-ce qu'ils démarrent ? Pour l'alimentation, c'est un peu plus compliqué. Le bloc peut délivrer juste assez de puissance pour lancer le démarrage mais n'arrive pas au maintenir une alimentation stable et s'effondre sur la charge. C'est une panne assez courante des alimentations à découpage.

Est-ce que le ou les voyants des disques, s'allume(nt) ? Il faudrait 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 pencherais pour un problème sur un des disques, ou un problème d'alimentation (bloc hs).

Ce tuto mériterait un bon rafraîchissement et des éclaircissements car un certain nombre de points ont évolué depuis sa dernière mise à jour et d'autres demanderaient un peu plus de développement. Vos notifications apparaissent probablement à cause de la tâche planifiée de mise à jour du container. Pour ma part, je n'ai jamais mis en place cette mise à jour parce que ça n'a guère d'intérêt. D'abord parce que le script acme.sh se met automatiquement à jour si besoin à chaque lancement journalier ensuite parce que la mise à jour de docker peut se faire directement dans container manager où on peut vérifier si le container acme est est à jour et l'actualiser si besoin. Comme il y a toujours des mises à jour d'autres containers, on y va relativement souvent. Pas besoin d'une tâche planifiée pour ça. Si ces notifications vous gènent, commencez par mettre la tâche planifiée en veilleuse pour vérifier que c'est bien elle qui les génère.

Comment espérez-vous qu'ils se créent ? Il faut bien que le dossier du ndd soit créé avec son fichier ndd.conf pour avoir la date de création et définir des dates de renouvellement et d'expiration. Sans cela, acme n'a aucune trace du certificat si vous le rentrez manuellement.

Il me semble que c'est bien expliqué dans le tuto. Les 3 premières lignes restent inchangées (http, IP, port), les autres sont à ajuster en fonction de votre environnement.