.Shad.

Ce n'était clairement pas évident à la lecture de ta demande. 😛

Ah je suis bien d'accord avec toi, je disais juste que dans l'absolu c'était prévu par Synology, mais ce n'est pas ce que je conseille dans mon premier message de toute façon. 😉

Ah ben moi je comprends l'inverse 😛 Ça me paraîtrait très bizarre qu'il veuille faire dans le sens dont tu parles.

Bienvenue 🙂 La section tutoriels devrait te dénéophyter (oui ça existe, depuis maintenant) :

Pour moi s'il prend les disques de son DS209j, qu'il les replace dans le même ordre dans son DS420j, DSM fonctionnera. Je dis que ce n'est pas souhaitable pour toutes les raisons qu'évoque en suite de mon message @Mic13710, mais dans l'absolu, sauf si j'ai loupé quelque chose, ça marcherait. Et dans mon message je conseille effectivement une installation from scratch, modulo le fait que je lui ai dit d'utiliser Hyper Backup et que @Mic13710 m'a justement rappelé que ça n'existait pas encore, je suis arrivé à DSM 6 moi je suis un jeunot. 😄

La suite de caractères qu'on voit dans ta dernière impression d'écran ne correspond pas à du tout à une clé publique, ni même privée. Voici ce que tu dois copier dans le fichier authorized_keys : Mon premier conseil est de reprendre le tutoriel, il y a eu visiblement une grosse confusion quelque part (voir ma première remarque). Si tu n'y arrives toujours pas, voilà un chemin alternatif : je te conseille de supprimer ton fichier authorized_keys actuel, et de recréer un fichier vide : touch ~/.ssh/authorized_keys On sécurise les accès : chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys Quand c'est fait, tu peux effectivement passer par vi, beaucoup d'utilisateurs ont suivi le tutoriel avant vous sans rencontrer de problème, donc c'est dans l'application des consignes que ça coince. Pour utiliser un éditeur de texte plus facile, tu peux télécharger le paquet SynoCLI File Tools de Synocommunity (voir ici pour ajouter ce dépôt si tu ne l'as pas déjà fait), il comprend nano qui est beaucoup plus simple d'utilisation que vi. nano ~/.ssh/authorized_keys Tu copies ta clé publique dans PUTTYgen (voir impression d'écran ci-dessus), et tu cliques droit dans la fenêtre SSH, ça va ajouter la clé, tu fais CTRL+O, Entrée puis CTRL+X pour sortir. Tu quittes la session SSH et tu tentes de te connecter via la clé comme le décrit le tutoriel.

Personnellement j'ai acheté le mien d'occasion à 300€ sur Fnac Marketplace, c'était une super affaire je le reconnais, mais sur des sites comme leboncoin on peut trouver des NAS d'occasion en très bon état. Mais c'est sûr qu'il faut regarder fréquemment et avoir un peu de chance.

Je ne pensais pas donner les droits homes, on laisse les droits par défaut à la création de l'utilisateur (accès au /home personnel si espace personnel de l'utilisateur activé, pas d'accès au dossier homes sauf s'il fait partie du groupe administrateurs). @Stixen92 dit qu'il arrive à voir le dossier home (sans s) sans y avoir accès, ça je pense que ça vient du fait qu'il a interdit l'accès à homes, qui comprend home). Le fait d'avoir juste la liste des utilisateurs dans Propriétés/Permissions d'un fichier/dossier ne représente pas de gros risques dans ces conditions selon moi, si le mot de passe est fort bon courage pour bruteforcer les autres comptes, surtout si le blocage auto est actif.

Si tu déplaces tes disques tels quels, ça fonctionnera mais tu vas embarquer tout un tas de limitations liées à l'âge de ton 209J, par exemple le système de fichiers de ton volume. Pour éviter ça, tu peux faire une copie manuelle de tes données sur un disque externe ou un périphérique réseau (PC, autre NAS, etc...), ou en utilisant Hyper Backup, qui embarquera la configuration de tes paquets et du système, en plus des données. Mais vu le saut de génération et de version de DSM, je profiterais à ta place de l'occasion pour reconfigurer le nouveau NAS "from scratch" en me basant sur le tutoriel de sécurisation du NAS : Une fois le NAS configuré, tu n'auras plus qu'à restaurer tes données, quelque soit la méthode choisir ci-avant. Attend les avis d'autres personnes quand même.

A partir du moment où les mots de passe sont suffisamment forts pour chaque utilisateur (et ça on peut décider de l'imposer à l'utilisateur via le Panneau de configuration), je ne suis pas sûr que ce soit très gênant que la liste soit visible ?

@Jeff777 : Pour ton souci de docker-compose incompatible avec le Rpi 1, je viens de voir que Linuxserver a sorti une image docker-compose, ça fonctionnera peut-être (vu que l'image docker-compose est basée sur une distribution compatible). A vérifier : https://hub.docker.com/r/linuxserver/docker-compose

La box a par défaut son IP LAN fixée, sinon elle reproduirait le même problème que tu as noté avec le serveur DHCP du NAS. C'est un périphérique qui doit initier une requête au serveur DHCP pas l'inverse, par conséquent aucune chance que ton NAS attribue une IP à la box. Ca n'explique pas ton problème, mais ça exclut celui que tu envisageais. Regarde peut-être que le masque de sous-réseau corresponde bien entre le serveur DHCP et l'IP de ta box, sûrement 255.255.255.0 (ou encore /24 en notation CIDR).

@Lelolo Pas mieux à proposer en effet, tiens-nous au courant.

Tu n'auras pas de solde sur les nouveaux modèles, qui ne viendront éventuellement que fin 2021, voire 2022. Je te conseille un DS918+, c'est un très bon produit, le DS920+ est un peu plus puissant mais sa RAM de base est soudée, contrairement au DS918+ dont les deux emplacements de RAM sont évolutifs. Oui sans problème. Ben si tu comptes faire tout ce que tu dis avec ton 4 baies, ça me paraît assez naturel de mettre le 2 baies à distance non ? Dans l'idéal oui, maintenant il faut voir ton budget. Selon moi, oui, perso j'ai un DS118 acheté 40€ d'occasion pour réaliser mes sauvegardes, c'est amplement suffisant.

Si le serveur refuse ta clé c'est qu'elle n'est pas correctement encodée dans le fichier authorized_keys. Reconnecte-toi sans la clé, et vérifie que la clé publique est identiquement présente dans le fichier authorized_keys.

De grandes chances que les accès à l'API ne soient pas bons, en tout cas pas suffisants pour supprimer des enregistrements dans ta zone.

Bienvenue parmi nous !

Je ne vois pas comment le NAS peut être en cause si ça fonctionne bien en wifi mais pas en 4G. A la limite des réglages sur DSM (encore que...), ou la puce 4G de ton téléphone.

Un peu plus d'info sur les racines de ton problème je pense : https://letsencrypt.org/fr/docs/ipv6-support/ La solution dans ton cas est d'avoir un enregistrement AAAA pointant sur l'IPv6 de ton NAS. Et que ton pare-feu soit ouvert au moment du renouvellement. Ce n'est pas le plus simple. Pour moi, le plus simple ce serait d'utiliser le nom de domaine Synology avec un wildcard, la vérification se faisant au niveau des zones DNS il n'y a aucun port à ouvrir. Sinon, tu as un DS920+, tu peux donc te servir de Docker, plusieurs solutions s'offrent à toi : - https://www.nas-forum.com/forum/topic/68046-tuto-certificat-lets-encrypt-avec-acmesh-api-ovh-en-docker-dsm67/ - plus complet encore, avec un proxy inversé et fail2ban intégrés : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ Ces solutions ont l'avantage de gérer la gestion et le renouvellement de certificats wildcard pour tout domaine, pas seulement Synology.

Essaie de mettre l'IPv6 du NAS et pas celle de la box. On évite de faire du NAS en IPv6. Et assure-toi que ta box autorisé le traffic IPv6 entrant pour ton NAS pour le port 80. Par défaut je pense qu'elle doit le bloquer. Si ça ne marche pas non plus je suis à court d'idées. Éventuellement désactiver l'IPv6 sur le NAS, ça forcera à passer par l'IPv4, ça coûte pas grand chose d'essayer.

Oui tout à fait.

Tout m'a l'air bon, sauf le fait que tu remettes le nom de domaine racine dans les alias, tu mets juste le domaine racine dans le premier champ, le mail dans le deuxième, rien dans le troisième.

Dans les deux cas la connexion est chiffrée, les débits devraient être équivalents. Le premier a l'avantage de ne pas demander d'ouverture de port supplémentaire et ne nécessite pas d'autres logiciels qu'un navigateur. Le deuxième doit permettre (je ne sais pas si c'est le cas) de programmer des téléchargements, ou de faire une liste d'attente.

DSM n'embarque pas la possibilité de créer des certificats wildcard pour des domaines autres que celui fourni gracieusement par Synology. Donc, pour rejoindre ce qu'a dit @Mic13710, je pense qu'il faut indépendamment créer tes sous-domaines dans ta zone DNS, tu peux quand même laisser l'enregistrement wildcard dans la zone cela dit, ça ne gêne pas, il n'y aura pas de conflit car les sous-domaines explicitement définis prennent le pas sur le wildcard. Ca aurait dû marcher ça par contre. Pour peu que le port 80 était accessible au moment de la demande de certificat.

Si tu remets les disques dans le bon ordre, le NAS devrait être tout de suite opérationnel. Vu que tu sépares les différents domaines d'utilisation (pro et perso) sur des NAS différents, tu as forcément le risque que si le NAS avec les données pro tomb en panne, tu sois obligé d'utiliser ton deuxième NAS et d'y importer les données pro en plus des données multimédia qui s'y trouvent déjà. Est-ce que tu ne peux pas tout mettre sur un même NAS ? et tu fais une synchronisation des dossiers partagés entre le premier et le deuxième NAS. En cas de panne d'un des NAS, l'autre pourra reprendre le relais de manière transparente. Une sorte de haute disponibilité bon marché. 😉 Et le troisième NAS servirait de destination de sauvegarde du NAS principal. Pour un NAS de sauvegarde, le basic me semble amplement suffisant. En revanche si tu veux vraiment protéger tes données au maximum, je te conseille de continuer à faire une sauvegarde au moins mensuelle de tes données sur un disque externe, et souscrire à un service cloud bon marché pour les données les plus importantes.