Mic13710

Ah oui, désolé @Will31, le message s'adressait @kinecrepet. Je corrige.

@kinecrepet cela vous a peut-être échappé, ce forum comporte des rubriques avec un descriptif pour chacune d'elle. Ici c'est pour les présentations et uniquement les présentations. Je déplace. Merci à l'avenir de respecter l'organisation de ce forum. Edit : correction de destinataire

@firlin c'est normal. Si le certificat est toujours dans la période de validité, le script se borne à faire cette vérification et ne va pas plus loin. Les messages dont je parle concernent le déploiement qui de ce que j'ai compris, ne s'est pas effectué correctement chez toi. Il faut le faire manuellement avec la commande suivante que tu lances dans une tâche : docker exec Acme sh -c "acme.sh --deploy -d 'tonNDD' --deploy-hook synology_dsm" Tu devrais voir normalement les lignes en question, renseignées ou pas. Tu peux garder cette tâche dans le gestionnaire mais sans la lancer. Tu ne t'en sers que si le déploiement ne s'est pas bien déroulé.

C'est normal : un certificat ne s'applique que sur un nom de domaine, jamais à une IP. Cependant, la liaison est bien chiffrée (et donc sécurisée) dès lors qu'elle se fait en https. Le https barré indique seulement que le site n'a pas de certificat valide et reconnu par une autorité de certification (Let's Encrypt par exemple) et qu'il n'est ainsi pas possible de confirmer son authenticité. Pour ce qui est des certificats, je vous conseille de vous reporter (et de mettre en pratique) le tuto sur la sécurisation de nos NAS sous DSM7.

@firlin il faut dé-commenter la ligne LOG_FILE="/acme.sh/acme.sh.log" dans l'account.conf

@CoolRaoul, c'est écrit en préambule de ce sujet : Le mode DHCP est bien par défaut dans DSM mais probablement que les réglages précédents ont été modifiés et que depuis la box a été changée, d'où l'incohérence.

Ce pourrait être une des causes de votre problème. Ces disques ne sont plus compatibles pour un montage en RAID du fait de leur techno SMR. Ils ont tous été retirés des listes par Synology dont les vôtres. Un sujet du forum qui en parle. Partant de là, il est malheureusement bien difficile de vous donner un conseil, hormis celui de remplacer tous vos disques. Pour le choix du RAID, je m'étonne qu'il se soit porté sur le 10 car si ce type de RAID permet de perdre 2 disques, il faut qu'ils soient sur la même branche en RAID0. Si vous perdez un disque sur chaque branche, les données sont perdues. Ce qui m'étonne aussi c'est que le RAID10 n'est pas un mode de stockage courant, que ceux qui le choisissent le font en connaissance de cause, d'où ma question. Je comprends à vous lire que vous l'avez choisi par méconnaissance de son fonctionnement. AMHA, vous auriez du vous orienter vers le SHR qui est proposé par défaut plutôt qu'un RAID exotique. Et si vous vouliez avoir une sécurisation sur 2 disques, vous aviez aussi le choix du SHR2 qui est un équivalent RAID6. Ce RAID accepte la perte de 2 disques, n'importe lesquels, dans le groupe. Personnellement, je ne vois aucun intérêt au SHR2 sur 4 disques de 4To. C'est beaucoup de stockage perdu (autant que le RAID10) sans réelle justification. Le SHR (combinaison de RAID1 et RAID5) offre une protection suffisante (perte possible d'un disque) et surtout de la flexibilité pour les augmentations de capacités futures, ce que ne permet pas le RAID10 qui lui est figé dans le marbre (pas possible de remplacer les disques par des plus gros sans tout casser). Et comme l'a dit @Lelolo avant moi, le RAID n'est pas et n'a jamais été une sauvegarde, seulement une sécurisation des données (continuité de service) en cas de perte d'un disque. C'est tout. Il est impératif de mettre en place une vraie sauvegarde périodique de vos données si vous ne voulez pas un jour les voir disparaître à tout jamais.

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.

Il faudra déplacer le dossier vers un volume plus gros ou remplacer le disque par un plus gros, recréer le groupe et le volume et restaurer vos sauvegardes. Mais avant cela, vous pouvez considérer de déplacer (ou d'archiver) des dossiers utilisateurs dans des dossiers partagés attribués à chaque utilisateur avec un accès exclusif pour y mettre des dossiers de moindre importance. Vous pouvez paramétrer aussi un quota par utilisateur pour limiter les stockages au strict nécessaire. C'est un peu comme le rangement chez soi : plus il y en a, plus on stocke des objets inutiles. Avec moins d'espace, on est obligé de trier. Mais bon, 16To de dossier homes, ça fait beaucoup de data et/ou beaucoup d'utilisateurs pour arriver à remplir autant.

Il faut éditer le premier message Le 218play n'est plus sous garantie. Synology ne pourra rien faire. Est-ce que le ventilateur tourne ? Le NAS n'a t'il pas tout simplement besoin d'un nettoyage ?

@ournit Y'a des corbeaux voyageurs en Nouvelle Calédonie ? 😉 Je doute que le problème vienne du slot, mais il se peut que des poussières altèrent les contacts. Vérifiez à nouveau. La cause la plus probable est un défaut du disque. Quel modèle ? Est-ce que vos disques sont dans la liste des compatibles pour le 420+ ? https://www.synology.com/fr-fr/compatibility?search_by=drives&model=DS420%2B&category=hdds_no_ssd_trim&display_brand=other Que disent les tests SMART ? Si votre version de DSM est 7.2, il faut pour cela vous connecter en SSH et sur un terminal (putty pour Windows) lancer la commande : smartctl --all /dev/sdx (x=a, b, c, d, etc..) Vu le lieu où vous habitez, je doute fort que le réseau électrique soit d'une stabilité exemplaire, surtout par les temps qui courent. Est-ce que votre NAS est connecté à un onduleur communiquant et compatible, et est-ce qu'il est reconnu par le NAS ? Question subsidiaire pour ma curiosité : pourquoi avoir fait le choix d'un RAID 10 ?

@firlin j'ai eu des problèmes de déploiement automatique sur le 220+ lors du dernier renouvellement. Le certificat était OK. Même manuellement, ça ne fonctionnait pas car le script n'arrivait pas à récupérer le SYNO_Session_ID et le SYNO_SynoToken ce qui bloquait le déploiement. Regarde tes logs, il est probable que ces deux variables soient nulles et que tu ais ce message : "Unable to authenticate to http://172.17.0.1:5000, you may report the full log to the community." Ce que j'ai fait, mais n'a pas servi à grand chose. https://github.com/acmesh-official/acme.sh/issues/2727 Mais après quelques jours et sans avoir changé quoi que ce soit, le déploiement manuel a fonctionné. Les mystères de l'informatique... A voir lors du prochain renouvellement.

Il est normal que Synology mettent ce message pour se couvrir car ils ne contrôlent pas les containers. C'est pareil pour les applications tierces. Je fais les mises à jour lorsqu'elles se présentent et tout se passe bien jusqu'à présent. Container Manager arrête bien le container. Et si d'aventure ça se passe mal, j'ai les sauvegardes qui peuvent m'aider avant de devoir réinstaller.

Oui @CoolRaoul, il y a deux écoles : les pour et les contre. Pour ma part, je suis contre pour au moins 2 raisons. La première est sur l'utilisation au quotidien. Lorsque les disques sont en hibernation, une requête devra d'abord redémarrer les disques avant d'aboutir et retourner la demande. Le temps de réponse est alors effroyablement long à l'échelle informatique. La deuxième est sur la gestion de DSM lui même. Pour ses propres activités, il a besoin de faire des lectures/écritures sur les disques. Il doit donc redémarrer des disques en hibernation pour lancer ses propres processus. Ces opérations sont aléatoires et difficilement contrôlables. Au final, les disques sont souvent sortis de l'hibernation que ce soit pour des demandes externes ou des processus internes ce qui limite l'intérêt de cette fonction dont le seul but est de répondre à des obligations de pseudos économies d'énergie imposées aux constructeurs. La réalité de ces économies est très discutable au vue de la consommation assez modeste de nos petites bêtes. Sans vouloir rentrer dans un débat sur l'impact effectif des économies de bouts de chandelles (IOT, téléviseurs, chargeurs de téléphone, etc..) dont nous bassinent les médias à longueur de journée, il y a infiniment plus a faire sur des postes qui sont gourmands en énergie (chauffage, production d'eau chaude, électroménager). Mais voilà, tout le monde est obnubilé par l'ampoule éclairée (c'est pas Versailles ici...) parce que c'est une consommation visible alors que ça ne dérange pas grand monde de prendre une douche d'une demi heure qui va entrainer une consommation d'énergie importante, mettant à mal les toutes petites économies faites par ailleurs. Quant à l'impact sur les disques, je n'ai pas de certitude. Cependant, je pense que les effets électrodynamiques et thermiques des redémarrages incessants contribuent à réduire leur durée de vie par rapport à des disques qui tournent 24/7. Et quand on voit le prix des disques, un remplacement prématuré coutera forcément plus cher que les quelques Euros économisés.

Malheureusement non. Il faut mettre à jour vos sauvegardes, supprimer le volume et le groupe, recréer un nouveau groupe sur chaque disque et un volume par disque, réinstaller les applications et restaurer les sauvegardes.

Pour info : la console d'OVH a changé. L'url d'accès aux API est maintenant celle-ci : https://api.ovh.com/console/?section=%2Fme&branch=v1#get-/me/api/application La présentation est très différente de l'ancienne mais on s'y retrouve assez facilement. A noter que la commande "Execute" est remplacée par "Try" L'ancienne console continue de fonctionner pour quelques temps encore à cette url : https://eu.api.ovh.com/console#/me/api/application~GET

@PiwiLAbruti j'ai lu un peu vite en effet. Ceci dit, le problème se posera par la suite, sauf si connexion via "slowconnect" 😛 L'IP est probablement OK puisqu'il y a eu des mises à jours de DSM. Un problème de paramétrage réseau est en effet une des causes du non fonctionnement.

Probablement que votre freebox est en CGNAT (partage d'IP). Vérifiez dans votre compte free si votre IP est en full stack et si besoin en faire la demande sur la même interface.

443 autorisé dans le parefeu du NAS ?

Pour la première erreur, l'adresse est résolue mais le serveur refuse l'accès (problème de droits ?). Pour la deuxième, l'adresse n'est pas résolue. Comme votre ndd est visible sur la deuxième vue, j'ai vérifié sa propagation et c'est bien votre IP qui est renvoyée. Il y a donc bien un problème à résoudre entre votre routeur et le NAS. Est-ce que vous avez fait la redirection du port 443 vers l'IP du NAS dans le routeur ? Et est-ce que le port 443 est autorisé dans le parefeu du NAS ?

Elle ne t'était pas destinée en effet 😉. C'était en réponse à : dont ses réglages le conduisent à DSM. Sinon, si tout est fait correctement comme tu l'as décrit, on devrait tomber sur webstation s'il est activé ou une erreur 404 si l'adresse ne peut pas être résolue, ou un site bidon si tu renvoies vers une url externe comme tu le dis.

Vous n'avez monté qu'un disque sur deux mais comme c'est un RAID1, ça doit passer. Votre groupe n'est pas un RAID classique mais hybride (SHR). Votre device_path est donc : /dev/vg1000/lv Vous continuez sur le point 13 avec le dossier de montage du point 6 et le device_path

C'est ici : https://www.nas-forum.com/forum/topic/77076-pour-ceux-qui-recherchent-les-anciennes-versions-de-dsm-srm-et-des-applis/

@Fennec72 Oui c'est possible. Les disques donnés dans les data sheet sont ceux qui représentaient la plus grosse capacité de l'époque. Pour savoir quels sont les disques approuvés, il faut consulter le site Synology, rubrique HDD/SSD. Le disque le plus gros pour le 713+ est 14To. https://www.synology.com/fr-fr/compatibility?search_by=drives&model=DS713%2B&category=hdds_no_ssd_trim

Non, Non, Non, trois fois NON !!!!!!! On ne cesse de le répéter à longueur de posts mais les idées reçues ont la vie dure : Le RAID permet d'assurer la continuité de service en cas de panne d'un disque, c'est tout. CE N'EST PAS UNE SAUVEGARDE !! Et vous venez de toucher du doigt pourquoi ça n'en est pas une...... Je vous conseille vivement de mettre en place une vraie sauvegarde périodique de vos données parce que là, ce n'est pas encore gagné et rien ne vous garantie que vous pourrez récupérer quoi que ce soit. Quand on met "toute une vie" sur des supports qui ne sont pas éternels, qui peuvent être effacés, vérolés, corrompus, détruits, on s'expose à les perdre à tout jamais. Autre kb : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_fix_hard_drive_failure_and_retrieve_the_data_from_your_hard_drives Pour récupération sur PC : https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC