Mic13710

Peut-être aussi que depuis bientôt 2 ans le problème a été résolu 😏 Le refus d'un OTP n'a que deux origines : clé OTP erronée ou décalage d'horloge.

Si je comprends bien, vous cherchez a pouvoir obtenir le code OTP à partir de plusieurs sources. Si c'est ça, la réponse est oui. Et c'est même indispensable si votre unique appareil tombe en panne. Vous pouvez le faire à partir d'autant de postes et d'applications que vous voulez : Google Authenticator, FreeOTP pour Android, KeeOTP pour Keepass, etc... Il y en a plein. Le plus important c'est que ces postes ainsi que le NAS soient connectés sur des serveurs NTP fiables pour avoir l'heure exacte. La seule information dont vous avez besoin, c'est la clé OTP qui a été générée par le NAS. Certaines applications permettent de la récupérer soit sous forme de texte, soit en QR code, soit les deux. FreeOTP par exemple permet d'avoir les deux. Si vous ne l'avez pas, la seule option qui vous reste est de renouveler votre double authentification en prenant soin cette fois de récupérer la clé générée. Je vous conseille vivement de sauvegarder cette fameuse clé car c'est elle seule qui peut vous permettre de générer le code OTP du moment à partir de l'application de votre choix.

Ca n'a pas d'importance. Une fois le disque sorti, bon ou pas bon, il faudra reconstruire le SHR. Vous pouvez sortir le disque sans le désactiver au préalable.

Là c'est autre chose. Il s'agit d'Active Backup for Business qui nécessite le BTRFS. Mais ce n(est plus une simple sauvegarde des données telle que définie dans les prérequis. Dans ce cas, oui il faut impérativement le BTRFS. Je me sers de cette appli sur mes deux PC sous W10 mais je n'ai pas encore eu l'occasion de pouvoir vérifier si c'est efficace. Je pense qu'il vaut mieux l'héberger sur le nas de prod (le 920+ pour vous) plutôt que d'investir dans un NAS compatible BTRFS pour cette seule raison J'aurais pu choisir mon 220+ pour cet usage, cependant mes deux sessions sont sauvegardées sur mon 718+ car c'est le seul accessible par internet.

A mon sens, le BTRFS ne se justifie pas. Son intérêt est surtout pour la virtualisation, les snapshots et la gestion du versionning. C'est donc plus approprié pour un NAS de production. L'EXT4 est largement à la hauteur pour du simple stockage de données. Le DS212 est probablement suffisant pour du stockage de masse, et même s'il s'avère un peu lent, ce n'est pas un critère important s'agissant de sauvegarde. Une heure de plus ou de moins, l'important c'est qu'elle soit faite. Après, rien n'empêche de se faire plaisir !

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.

pour une plage de 192.168.1.1 à 192.168.2.254, le masque de sous-réseau est 255.255.254.0 ou en notation courte : 192.168.1.0/23 Un peu de lecture : https://fr.wikipedia.org/wiki/Sous-réseau Sujet déplacé dans la bonne rubrique.

Je laisse le soin à d'autres de répondre (@Einsteinium ?) De mon côté, mes deux registar étant différents, je n'ai qu'une seule instance docker pour les deux.

Je ne saurais dire. Les variations d'une version à l'autre peuvent avoir un effet sur les applications et c'est probablement dans le cas présent une meilleure gestion des unités de stockage avec DSM7.2, ou alors une amélioration de la synchro. En tout cas, c'est rassurant de savoir que ça fonctionne correctement. Pour en revenir à ce que je disais à propos d'un dossier vierge, tout d'abord c'est ce qui était la règle avec feu Cloudstation. Mais l'expérience m'a montré que même si Drive autorise la synchro de deux dossiers non vierges, il arrive que cette synchro ne se fasse pas correctement et très souvent pour des questions de droits. C'est exactement ce qui arrive @Phil_69. C'est pour cette raison que le départ sur un dossier vierge est préférable.

La seule chose possible c'est de supprimer le groupe existant (et donc perte des données) et de reconstruire un ou plusieurs groupe(s) pour y importer vos sauvegardes que vous avez surement prévues depuis le départ. Donc pas de stress. Sinon, faire des sauvegardes en local n'est pas à proprement parlé une sauvegarde qui doit être désolidarisée de la source et dans un autre lieu.

J'avoue ne pas bien comprendre la question. Le masque 255.255.0.0 pour une ip en 192.168.0.1 donne une plage allant jusqu'à 192.168.255.254, soit 65534 adresses. Qu'est que vous voulez faire avec toutes ces adresses alors que le NAS ne peut pas toutes les traiter ? https://jodies.de/ipcalc?host=192.168.0.1&mask1=8&mask2= Et comme vous avez posté dans la section du serveur DHCP, c'est donc du serveur du NAS qu'il s'agit. Pouvez vous nous expliquer le pourquoi du comment d'une telle plage d'adresses sur un réseau privé ? Maintenant, s'il s'agit du parefeu, votre question n'a rien à faire dans cette section, et je vous invite à aller consulter le tutoriel concernant la sécurisation de nos NAS pour savoir comment autoriser les plages d'ip privées.

@Charles 69 et donc si je comprends bien, ça fonctionne ?

@niklos0 c'est vrai que contrairement au SHR le RAID demande parfois une augmentation de groupe. Je crois que ça dépend de la version de DSM. @Jean Louis DURET verra bien s'il faut le faire en fin de processus.

@Torvic-Gall Tout d'abord, merci de ne pas citer inutilement le post précédent. Ca n'apporte rien de plus à la compréhension. Tout au plus, faite une citation du passage auquel vous répondez. Régistar c'est un fournisseur de ndd. Il n'est pas plus compliqué que celui-ci. Comme je l'ai dit, la méthode est la même. L'obtention des clés, la création du certificat ainsi que le déploiement sont similaires et les instructions itou. C'est juste leur emplacement et le lancement qui sont différents. Comme je suis dans un bon jour, voici un petit tuto que je m'étais fait à partir du tuto de Neilpang : Création du certificat Let’s Encrypt par la méthode acme.sh Installation de acme.sh Via putty en root : sudo su $ cd ~ $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz $ tar xvf master.tar.gz $ cd acme.sh-master/ $ ./acme.sh --install --nocron --home /usr/local/share/acme.sh --accountemail "email@gmailcom" $ source ~/.profile Création du certificat pour ndd (OVH) On exporte les clés de l’API précédemment créée par : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* export OVH_AK= "your application key" export OVH_AS= "your application secret" export OVH_CK= ”your consumer key” génération du certificat : cd /usr/local/share/acme.sh ./acme.sh --issue --keylength 4096 -d ‘ndd’ –d ‘*.ndd’ --dns dns_ovh Une fois le certificat créé, il faut l’importer dans DSM. Pour cela, via WinSCP en root, on va dans /usr/local/share/acme.sh/ndd et on copie dans un dossier du PC ndd.cer, ndd.key et ca.cer Dans l’onglet certificat de DSM, on crée un nouveau certificat qu’on nomme par exemple « Wildcard ndd» dans lequel on importe les 3 fichiers du certificat et on valide. Le certificat créé dans DSM, il faut maintenant lui attribuer les services qui y seront rattachés (cad, tous ceux utilisant le certificat LE ndd). Bouton Configurer. On désigne par la même occasion le certificat comme étant celui par défaut. Il faut maintenant procéder au déploiement du certificat pour tous les services auxquels il a été affecté. Dans putty : export SYNO_Username='acme' (utilisateur admin créé uniquement pour le certificat) $ export SYNO_Password='your password' $ export SYNO_Certificate="Wildcard ndd" $ ./acme.sh --deploy --home . -d ndd --deploy-hook synology_dsm Enfin, il faut que le renouvellement et le déploiement soient automatiques. On crée une tâche qui va réaliser tout ça dans le planificateur : Utilisateur - root Périodicité: Setup a weekly renewal. For example, 11:00 am every saturday. Task setting: User-defined-script: # renew certificates /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/ C'est tout. Rien de vraiment compliqué par rapport au tuto de ce fil.

C'est possible mais si le registar est le même, il va falloir créer une deuxième instance ACME. Ceci dit, docker n'est pas indispensable. On peut très bien utiliser le même principe directement dans DSM. C'est ce que je faisais sur mon 214+. https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide

Puis je savoir quel est le rapport entre votre question est la section "Monitoring de votre NAS" ? Je déplace. Plus simple que ça, c'est difficile. Oui, vous sortez un des disques, vous insérez un nouveau, vous allez dans le groupe de stockage pour réparer le groupe. Une fois l'opération terminée (quelques heures), vous faite de même avec le second disque. Ce n'est que lorsque l'opération sera terminé que votre stockage augmentera. Il faudra bien entendu éteindre le NAS entre chaque opération.

Ca aussi c'est à proscrire et c'est expliqué dans le tuto sur la sécurisation de nos NAS cité par @DaffY

J'ai eu une seule AP TPlink et c'était une vraie bouse. Depuis, j'ai banni leur matériel et je suis passé à Ubiquiti. Plus de problèmes de déconnexions, d'incompatibilités, ça fonctionne 24/7 sans interruptions. Peut-être une explication dans le différent qui oppose la Chine (TPLink) à Taiwan (Synology) 🤐

@syn1077 ça vous arrive de faire des recherches personnelles ? Si vous utilisez SS, vous avez bien remarqué qu'il y a un accès aux différentes rubriques par le pavé en haut à gauche ? Je vous laisse découvrir celle qui concerne les logs.

Là c'est plus clair, et c'est non. Il va falloir patienter et peut être revoir votre protocole de communication.

Votre demande est loin d'être claire. S'il s'agit de monter le disque du 213j dans un boitier USB pour récupérer les données, c'est impossible car le disque est en réalité un RAID monodisque. Pour pouvoir le lire, il faut le monter dans un PC sur un connecter sata dispo et utiliser une distribution Linux sur laquelle on installe mdadm et éventuellement lvm2 si le disque est en SHR. Si par contre vous voulez monter le disque dans un boitier externe et que vous le formatez pour pouvoir y stocker des données, la réponse est oui.

Non. Ils sont identiques mais non synchronisés. Pour la même raison que si dessus. Il faut bien que Drive construise le dossier de suivi qui n'existe pas. Et comme vous vous retrouvez avec des fichiers identiques mais non synchronisés et avec des droits différents, c'est la pagaille. Oui. Pour que la synchro se fasse efficacement, il faut partir d'un dossier vierge d'un des côtés, que ce soit côté client ou côté serveur. La synchro se fera alors du dossier contenant les données vers le dossier vide. Tout ce qui suit de votre laïus découle du fait que vous n'avez pas respecté le démarrage sur un dossier vierge. Primo, je ne vois pas l'intérêt d'avoir à la fois une synchro sur le PC et sur un disque externe connecté à ce même PC. Deuxio, je ne vois pas comment vous pouvez synchroniser deux dossiers sur un client (le PC et le disque externe) qui pointent tous les deux vers le même dossier du serveur.

La protection des données permet d'assurer la continuité de service en cas de défaillance d'un disque. C'est tout, mais ce n'est pas rien car sans cela, si un disque flanche, il faut alors le remplacer et y importer les sauvegardes pour retrouver les données. Pour un maximum d'espace, vous avez aussi le RAID0 ou le JBOD. Dans ce cas vous n'avez qu'un seul groupe de stockage mais la perte d'un disque signifie la perte totale des données. Et là, il n'y aura que vos sauvegardes pour pouvoir tout récupérer. Quelle que soit le mode de stockage choisi, il faudra TOUJOURS prévoir des sauvegardes périodiques des données, au moins les plus importantes.

Il n'y a pas ce souci. Comme @bagou91 l'a expliqué, SS fait le nettoyage des enregistrements qui ont un certain âge, et ceci en fonction des paramètres que vous avez indiqués dans l'application. Et comme vous avez probablement chaque jour des enregistrements, SS supprime tous les jours les enregistrements qui ont atteint la limite d'âge. Si cela ne vous convient pas, c'est que votre paramétrage n'est pas bon et il faut le modifier. C'est dans le menu "Log" que ça se règle.

Peut-être que les IP des AP sont bloquées par le parefeu du NAS.