Mic13710

A voir si cela peut vous aider ; https://kb.synology.com/fr-fr/DSM/tutorial/Unable_to_Locate_NAS

Faire un reset mode 1 : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS#x_anchor_id5

Aucun. Les disques n'apprécient pas d'être arrétés redémarrés. Il est préférable de les laisser tourner 24/7.

Apparemment non car si c'était le cas, le disque ne serait pas marqué "Désactivé" mais comme "initialisé" ou "non initialisé". S'il est marqué Désactivé, il ne peut pas être intégré au groupe. Votre disque n'est pas vieux (1120 heures), mais aussi je vois que les items 3, 4, 12, 192 et 193 sont à des niveaux élevés, ce qui indique clairement des arrêts et démarrages fréquents. Vous avez probablement activé la mise en veille des disques et du NAS. Je vous conseille de les désactiver.

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.

@Pout Comment peut-on poster un sujet dans la section seagate qui n'a strictement aucun rapport avec la question posée ? Je déplace. On ne peut pas dissocier les tâches sur un même compte d'un même client. On ne peut pas non plus spécifier différents nombres de versions. Le nombre de versions s'applique à l'ensemble.

Ces 2 VPN sont dans la même plage ? Il faudrait en changer une. Il semblerait que ce soit un problème de serveur DNS. Lesquels avez-vous indiqués ? Est-ce que vous arrivez à pinger l'IP 8.8.8.8 ? Que donne un nslookup 8.8.8.8 ?

@Pommefrais3 l'Ip dans l'account.conf n'est pas correcte. Elle devrait être celle de docker 172.17.0.1. Je suppose que le port 5050 est le http de DSM. Sinon il faut le changer. Supprimer le Saved_Syno_Certificate (il ne fallait pas copier exactement ce qui est écrit dans le tuto mais mettre le nom qui est donné au certificat dans DSM). De toute façon, il fait doublon avec celui en base64 qui est dans le ndd.conf

Je n'ai pas dit que ça règlerait quoi que ce soit. C'est tout bonnement une question de sécurité. Vous n'avez pas répondu à cette question : En migrant les disques ? Si c'est le cas, vous auriez du nous demander, on vous l'aurait fortement déconseillé car votre 923 fonctionne maintenant en mode dégradé, tout du moins, vous ne pouvez pas pleinement l'exploiter (taille maxi d'un volume, pas de btrfs ni snapshot ni virtualisation, des applications inaccessibles). De plus, cette migration peut très bien avoir cassé des mécanismes. Je ne saurais trop vous conseiller de mettre à jour vos sauvegardes, de casser le groupe actuel, de recommencer une installation à partir de zéro et de restaurer vos sauvegardes Un peu de lecture : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_between_Synology_NAS_DSM_6_0_HDD Si c'est vers l'IP du NAS, ce n'est pas une bonne idée : tous les ports ouverts dans le parefeu du NAS sont accessibles de l'extérieur.

Et si vous lisiez ce que je vous ai écrit ? Il faudrait aussi commencer par faire ce que dit le message de la vue 2, à savoir : Désactiver le disque (bouton action). Attention de bien choisir le disque en panne. Si vous vous trompez, vous perdrez toutes vos données. Vous sortez le disque et le réinsérez à chaud (votre NAS le permet). Vous réparez le groupe. Si le disque est encore bon, le RAID devrait se reconstruire.

Je parlais du parefeu du NAS...

Déjà, vous pouvez supprimer la redirection de ces deux ports, surtout le 5000. Le 5001 n'a pas d'utilité dans la mesure où vous avez une règle de proxy qui fait le taf (la première de votre capture ci-dessus) Dans votre proxy inversé, inutile de mettre des ports https pour la destination. Utilisez les ports http correspondants aux services, par exemple 5000 au lieu de 5001. A moins que vous n'ayez aucune confiance dans les utilisateurs de votre propre réseau, il n'est pas nécessaire de chiffrer les transmissions internes. Avez-vous activé la redirection automatique des connexions http vers https dans l'onglet DSM du portail des connexions ? Si oui, il faut le désactiver car cette option casse le mécanisme du reverse proxy.

C'est probablement un blocage au niveau du parefeu du port 6690 vers l'IP du NAS. Essayez en désactivant le parefeu.

Est-ce que SDC se connecte bien en local avec l'IP locale ?

Depuis le gestionnaire de stockage, HDD, Disque 1, bouton infos sur la santé, onglet SMART, bouton Détails en bas de page. Si vous n'avez pas fait de test étendu : Test étendu, bouton démarrer.

Que donnent les relevés smart étendus sur le disque en panne ?

@Oteomhu Si vous utilisez quickconnect, il n'y a rien de particulier à faire sur la freebox. Vous avez changé d'opérateur, il faut simplement remettre à jour le ddns comme expliqué dans le post juste au dessus du votre.

@steph31140 Nous ne le répèterons jamais assez semble t'il, il ne faut surtout pas ouvrir le port http 5000 vers l'extérieur. C'est ouvrir en grand la porte du NAS à des attaques. Si on doit accéder à DSM de l'extérieur, au pire on ouvre le https (5001). Je dis bien au pire car l'accès à DSM ne sert normalement qu'à l'administration du NAS et ces opérations ne devraient se faire qu'en local. @firlin et @DaffY l'ont dit avant moi et vous ont donné des pistes pour sécuriser les accès à votre NAS. A vous de voir quel est le degré d'importance de vos données.

J'ai halluciné en voyant le boitier. Quelle régression !

Bonjour @galaxyto, soyez le bienvenu. Un 415+? Hum, je ne voudrais pas vous porter la poisse. Il faut tout de même que vous sachiez où vous avez mis les pieds, ou plutôt vos données.

Tu ne l'avais pas dit dans ton sujet précédent. As-tu vu la note dans config.ovpn concernant ipv6 ? # If you want to connect by Server's IPv6 address, you should use # "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode proto udp Voir ce fil : https://community.openvpn.net/openvpn/wiki/IPv6

Quels ralentissements ? La réponse d'un serveur DNS local se chiffre en quelques millisecondes, celle du reverse proxy itou. C'est sûr que toute requête passant par le serveur local avant d'aller interroger un serveur public sera forcément plus longue que d'interroger un serveur public directement. Mais c'est insignifiant en terme de temps de réponse supplémentaire.

Ce ne sont pas des modifications obligatoires. Pour la plupart ce sont juste des réglages pour annuler certains messages d'erreur. A mon avis, tu t'es un peu trop vite précipité pour passer en 7.2. Perso, je vais faire comme d'hab : temporiser avant de franchir le pas. Je vois déjà que certains sont à la peine avec cette nouvelle version. Quelques updates devraient résoudre les toujours trop nombreux problèmes qui sont le lot de chaque nouvelle version. Mais en attendant, je vais me contenter de la 7.1.

Il y a d'autres choses comme par exemple dhcp-option DNS qui donne le ou les serveurs DNS à utiliser, modifier "cipher AES-256-CBC" en "data-ciphers-fallback AES-256-CBC", rajouter "auth-nocache" avant le certificat, et peut-être d'autres bricoles.

Le reverse proxy n'est pas une obligation puisque vous pouvez toujours transférer les ports vers chaque application. Mais c'est tout de même plus simple d'atteindre une application comme file station avec une URL du type https:\\file.ndd plutôt que https:\\ndd:7001. Le serveur DNS peut être installé sur le routeur, le NAS, un Raspberry, ça n'a pas d'importance tant que vous indiquez son IP dans le DHCP pour qu'elle soit transmise à tous les équipements susceptibles de l'utiliser. Il n'est là que pour renvoyer une IP pour un ndd donné. C'est tout. Il ne peut pas vous diriger vers une application particulière qui elle correspond à un port particulier. Le reverse proxy ne fait que diriger une requête donnée vers l'appli correspondante. Par exemple, diriger l'URL https:\\file.ndd vers le port 7000 du localhost qui correspond à l'application.