Mic13710

Dans le gestionnaire de stockage, fenêtre du volume, cliquer sur les trois points en haut à droite, Paramètres. Réglage en bas de page. Le seuil d'alerte par défaut est à 20%.

J'avoue ne pas bien comprendre l'utilisation d'un port exotique 61718. Pour quoi ne pas avoir dirigé directement le 65001 vers le NAS ? Le certificat concerne donc nom.synology.me. Il ne s'applique qu'à ce ndd, pas à un autre. Il est normal que toute requête faite sur votre sd.domaine vous donne la réponse que vous avez puisqu'il n'y a pas de certificat qui le couvre.

Bonjour @Didier Chauvin, soyez le bienvenu.

Très souvent, des disques qui sont rejetés par le NAS fonctionnent parfaitement sur un PC. C'est juste que les exigences d'un NAS sont plus élevées et que ce genre de situation arrive. Ce qui est plus rare c'est qu'il y ait les deux disques non reconnus. Avez vous fait le test de la CM ? 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 Faite aussi un test de la mémoire : https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_run_a_memory_test_on_my_Synology_NAS

La vitesse de transfert ne sera pas plus rapide avec Drive. C'est surtout l'ensemble réseau-NAS qu'il faut améliorer.

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 rejoins @Lelolo sur le besoin d'un forfait fibre costaud et d'un NAS à la hauteur. Un 218j me semble bien léger pour faire face à une forte demande. Je ne vois pas l'intérêt d'utiliser Drive pour des téléchargements. Ce n'est pas du tout la fonction première de cette application et ce serait très lourd à gérer. De simples liens de partage créés à partir de file station devraient faire l'affaire. P.S. : merci de ne pas citer inutilement le post précédent.

Il faudrait pour cela passer par Surveillance Station. Votre caméra n'est pas dans la liste des compatibles, et à moins qu'elle soit onvif, il y a peu de chance de pouvoir la faire reconnaitre par l'application. https://www.synology.com/fr-fr/compatibility/camera?brand[]=Synology P.S. : il y a des rubriques sur ce forum dont une pour surveillance station. Je déplace. Merci de lire les descriptifs de chaque rubrique avant de poster.

Bonjour @lule Pour commencer, ici ce n'est pas un hall de gare. De plus on donne un titre explicite à sa demande. Je vous invite à consulter les règles de ce forum : https://www.nas-forum.com/forum/guidelines/ Une fois celles-ci bien comprises, vous pourrez revenir poser votre question qui a bien entendu une réponse dans la section appropriée, à condition bien entendu de faire un minimum d'effort de recherche. En attendant, je verrouille ce sujet.

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