Audio

Pour finir j'ai mis à jour manuellement mes 2 autres NAS DS 920+ et sans mauvaise surprise.

Bonjour @mick45000 D'après le log [Mon Dec 29 21:44:30 CET 2025] Failed to authenticate, no such account or incorrect password] ce que tu as mis comme nom d'utilisateur et de pwd n'est pas connu du NAS. Ne pas laisser "utilisateur" et "mdp", il faut mettre le nom et le pwd d'un compte qui soit administrateur du NAS. Cordialement Audio

Bonjour, Pour ma part seul 1 de mes 3 DS 920+ a été mis à jour automatiquement. Tout fonctionne bien après le nettoyage des anciens paquets PHP. J'attends pour la mise à jour des 2 NAS restant. Peut-être procéderais-je en manuel pour l'un des 2. J'espère que je n'aurais pas de mauvaises surprises lorsqu'il faudra changer des disques durs! Bonne journée

Bonjour, Je relance ce sujet car j'ai eu des déboires assez similaires à ceux que @grizzli06 a expérimenté avec une VM Linux sous VMM, en particulier la touche Alt gr inopérante (voir son sujet dédié https://www.nas-forum.com/forum/topic/77944-virtual-machine-manager-touche-alt-gr-inopérante/ du 13 octobre 2023). J'ai installé une distribution Debian 13 Trixie sur VMM et je dois dire que la connexion à cette VM c'est pas le top avec noVNC dès lors qu'on veut utiliser une URL, dans mon cas debian.ndd.tld, en passant par un proxy. Il est clair que ça ne fonctionne pas. Il faut connecter d'abord VMM sur son port dédié renseigné dans le proxy (obtenu dans Portail de connexion > Applications) puis presser le bouton connexion sur la vm dans VMM. Pas très pratique! Heureusement j'ai découvert une solution bien documentée permettant de se connecter directement depuis Windows 11 par son application Bureau à Distance moyennant l'installation du paquet xRDP dans Debian. https://www.it-connect.fr/comment-se-connecter-en-rdp-a-debian-10-avec-xrdp/ C'est facile à mettre en place et à configurer que ce soit côté Debian ou Windows. Et la touche Alt gr fonctionne tout de suite 😄 Bonne journée à tous Audio

Bonjour @Mic13710 et @CMDC Vous avez raison tous les 2, le container est effectivement effacé puis recréé. Je pensais au script acme.sh lui-même et pas au script d'Eisteinium dans le planificateur de tâches de DSM. De mon côté la tâche de vérification/mise à jour d'acme.sh est depuis toujours programmée qu'une fois par semaine (réminiscence du temps où j'utilisais la méthode acme.sh en direct). Ayant installé Watchtower pour d'autres applis sous Docker (1 run par semaine), je pourrais peut être lui confier la mise à jour de neilpang/acme.sh, comme indiqué par Einsteinium dans le fichier Docker Compose. Cordialement

Bonjour @CMDC, Je ne pense pas que le container ACME soit "détruit et recréé" tous les jours. D'après le log acme.sh.log c'est un test sur la date de renouvellement qui est fait tous les jours. Si on a pas dépassé la date "Next renewal time is: YYYY-MM-DDTHH:MM:SS" alors le process de renouvellement n'est pas enclenché. Maintenant on peut toujours se dire que ce n'est pas la peine de faire cette vérification quotidiennement. Depuis que j'ai opté pour la méthode sous Docker au lieu de celle sous acme.sh il y a plus de 2 ans, je n'ai plus de soucis de renouvellement. Une fois par semaine j'ai la tache automatique qui regarde si il y a ou non une nouvelle image neilpang/acme.sh et l'installe s'il y a lieu. Cordialement Audio

Merci @PiwiLAbruti pour l'adresse de ce site de test. C'est effectivement détaillé. Toutefois le site de test ne vérifie pas pas le reverse DNS à partir de l'adresse IP du serveur mail. Le test ne porte que sur SPF, DMARC et DKIM.

Bonjour @Mic13710 Je suis aussi chez OVH, j'ai eu un renouvellement ACME le 29 juin et le log acme.shog est tout à fait normal. Bonne journée