Mic13710

Vous ne verrez jamais vos volumes sur un explorateur. Linux considère le stockage comme un ensemble et ne voit que les dossiers partagés, peu importe leurs emplacements. C'est à vous à donner un nom à vos dossiers et de les répartir sur vos volumes dans DSM. Et pour qu'ils soient accessibles, il faudra bien entendu leur attribuer des droits pour chaque utilisateur.

Peu de chance que ça fonctionne. Vous nous direz le résultat. Il n'y a pas de disque système. La partition système est sur tous les disques et fonctionne en RAID1. Une sauvegarde locale n'est pas à proprement parlé une sauvegarde. Si vous êtes victime d'un virus ou d'un cryptolocker, il y a toute les chances pour que l'ensemble des volumes du NAS soient affectés. Perso, je ne monterais qu'un seul groupe avec un seul volume et j'opterais pour une sauvegarde externalisée. C'est ce que je fais avec mes deux NAS.

Je ne comprends pas cette histoire de jeton URL puisqu'il ne s'agit pas d'une URL. Chez moi, quand je scanne le QR code généré pour le compte par DSM avec FreeOTP+ (petite icône appareil photo en bas à droite de l'appli), ça rajoute une entrée et la clé enregistrée qui s'affiche pour cette entrée est bien celle qui a été générée. Je viens encore de le tester à l'instant.

C'est vrai. Mais comme je le disais plus haut, certaines applications permettent d'afficher à la fois le QR et le code. C'est le cas par exemple de FreeOTP+. On scanne le QR avec l'appli et une fois qu'il est rentré, on peut afficher le QR code ou en cliquant sur modifier, afficher les infos dont cette fameuse clé. De la page de la clé bien évidemment, celle que j'ai montré plus haut ! Ou simplement l'enregistrer dans un logiciel de mdp comme par exemple keepass.

C'est à la création dans le menu Perso de l'utilisateur. En choisissant la double authentification, une page s'ouvre et deux ou 3 clics après, un QR code apparait.

Ce n'est pourtant pas bien compliqué. Vous cliquez sur Vous ne parvenez pas à le scanner ? C'est cette clé qu'il faut sauvegarder.

Je crains fort que ce soit impossible, du moins pas à notre niveau. Les seuls à pouvoir vous aider serait l'assistance Syno que vous pouvez contacter directement à partir de DSM.

Allez, je lance un pari : vous ne nous l'avez pas dit mais vos disques sont migrés d'un ancien NAS avant le 418. La migration des disques migre aussi les limites du NAS sur lequel ils ont été initialisés. Votre ancien NAS avait une limite de volume de 16To, ce qui explique que vous ne pouvez pas aller au dela. Deux solutions : soit monter un deuxième volume avec la capacité restante, soit supprimer le groupe et le recréer avec un volume sur la totalité du groupe et restaurer vos sauvegardes sur ce volume. La meilleure solution est bien évidemment la deuxième. C'est celle aussi qui demandera le plus de travail mais vous permettra de lever les limitations de votre groupe et pouvoir surtout bénéficier du BTRFS alors que vous n’êtes qu'en EXT4 je présume.

Il n'y a pas qu'avec votre NAS que vous avez des problèmes. Pourquoi renouveler 3 fois le même message en moins de 20 min ? Je masque les deux autres demandes. Merci de faire attention la prochaine fois.

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.