Mic13710

Le but du chiffrement c'est tout de même de protéger les données. Sans la clé, et sauf à tomber sur un voleur capable de casser un chiffrage AES ou RSA (il ne doit pas y en avoir des foules), il est impossible de lire les données. Par contre, je crois que si votre NAS tombe en panne, le seul moyen serait de remonter les disques dans un autre NAS Synology pour pouvoir déchiffrer et récupérer vos données. A confirmer.

@PiwiLAbruti j'ai bien parlé de nslookup dans mon message 😉

Sauf cas très particulier, pour des questions de sécurité, on évite de transférer les ports http vers le NAS. Je pense qu'il est inutile dans le cas présent de transférer le 80 et le 5000. Le 443 n'est utile que si le reverse proxy et/ou le serveur web sont utilisés sur le NAS. Et si le reverse proxy permet de rejoindre le 5000 ou le 5001 du NAS, il n'est pas utile de transférer le 5001. D'autres ports sont peut-être à rediriger comme par exemple le 6690 si Drive est utilisé, ou bien le 1194 pour open VPN, etc... Bref, tout dépend des services actifs et des paramétrages du NAS.

Dans l'invite de commande windows : tracert <votre nom de domaine> doit en un saut vous donner le temps de traitement, le nom et l'IP du NAS. Si vous avez plus d'un saut dont le premier correspond à l'IP de la box, votre requête transite par la box. Vous pouvez aussi utiliser nslookup <votre nom de domaine> Cette commande doit vous indiquer l'adresse du serveur qui a résolu le ndd. Ce sera l'IP du NAS si le serveur local à fait son travail.

@oracle7 Je n'ai pas suivi rigoureusement le tuto car je travaille sur une seule session docker pour le renouvellement de deux certificats. En conséquence, j'ai déplacé les variables de chaque certificat dans leur ndd.conf respectif, ce qui explique les structures différentes. Tout fonctionne ainsi depuis des mois sans faillir, jusqu'à aujourd'hui. Je ne vais pas épiloguer des heures sur le fonctionnement du script ni comment il récupère et sauvegarde les variables en y ajoutant un SAVED_. Je n'en ai ni l'envie, ni le temps. Je sais simplement que si les variables nécessaires au déploiement sont présentent dans les fichiers conf (account.conf ou ndd.conf) elles sont utilisées pour le déploiement, peu importe au final dans quel conf elles se trouvent. Ce dont je suis sûr maintenant pour l'avoir testé à l'instant sur mon 718 qui vient lui aussi de rater son déploiement, c'est que le problème n'est pas causé par l'emplacement des variables mais bien par le nom du certificat tel qu'il est enregistré en base 64 dans le conf. J'ai tout simplement remplacé la ligne SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_' par SYNO_Certificate='nom du certificat' Et là le déploiement s'est déroulé comme un charme. Par ailleurs, la ligne SYNO_Certificate est restée inchangée après le déploiement, ce qui est une bonne chose pour le prochain renouvellement. Ce que je ne comprends pas encore c'est que les variables SYNO sont traitées par synology_dsm.sh. Ce script n'a pas été modifié depuis fin septembre or j'ai eu des renouvellements sur plusieurs NAS après cette date qui se sont déroulés sans aucun problème. C'est peut-être lié à la dernière version foireuse de acme.sh mais je n'en suis pas sûr. Pour moi, le souci est temporairement résolu. J'attends de voir si une nouvelle version de l'un ou l'autre script apportera une solution à ce problème de récupération du nom en base 64.

On n'a pas du tout les mêmes fichiers. Le account.conf (en tout cas chez moi) ne contient QUE les clés API. LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 UPGRADE_HASH='xxxxxxxxxxxxxxxxxxxxxx' USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXXXXXXXXXX' SAVED_OVH_AS='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' SAVED_OVH_CK='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' Je n'ai rien de plus dans ce fichier Il n'y a aucune donnée utile pour le déploiement. Je n'ai donc rien à modifier dans ce fichier. Mais il est vrai que je ne suis pas tout à fait dans la même configuration que le tuto puisque je renouvelle deux certificats OVH d'un même compte client dans la même instance docker avec les mêmes API. Chez moi, toutes les données utiles pour le déploiement se trouvent dans le fichier ndd.conf du dossier nommé ndd. J'ai un dossier par ndd. Vas à la troisième vue de mon intervention ci-dessous pour voir comment est structuré chez moi un de ces fichiers. Et donc, c'est bien dans ces fichiers que se trouvent chez moi les fameux SAVED_ à modifier, pas du tout dans le account.conf. Pas vraiment non. Lors du déploiement, les fameux SAVED_ sont justement exportés et prennent le pas sur les éventuels export qui ont pu être fait précédemment sur ces mêmes valeurs. C'est exactement ce qui s'est produit lorsque j'ai tenté un export des données (vue 4 du même lien ci-dessus). Le nom du certificat n'est pas passé et a été supplanté par celui du ndd.conf en base 64. Et hormis cette histoire de nom de certificat qui ne passait pas, toutes les valeurs contenues dans les SAVED_ ont bien été rapportées dans les logs, preuve qu'il est nul besoin de les exporter. Et si tu reprends mon message précédent, tu verras que je n'ai pas fait d'export de quoi que ce soit. Je n'ai fait que supprimer les SAVED_ et mettre le nom du certificat en clair. Ensuite, un simple : docker exec Acme sh -c "acme.sh --deploy -d 'ndd' --deploy-hook synology_dsm" a exporté les données et déployé le certificat. Je pense au final qu'il y a un problème sur la conversion base 64 du nom du certificat dans la dernière version 3.0.6 d'acme.sh. qui n'affecte bien entendu que ceux qui spécifient un nom !

@Dimebag Darrell, il me semble pourtant vous avoir expliqué l'intérêt d'un serveur local dans un autre post. Et c'est aussi expliqué par Fenrir dans son tuto. Si votre FAI et votre box autorisent le loopback, le serveur DNS est moins utile, bien que dans ce cas, il permet d'éviter de transiter par la box pour des requêtes locales. Mais comme je vous l'ai expliqué, le serveur local ne peut fonctionner que si vous avez accès aux IP des serveurs DNS propagés par le DHCP de votre routeur pour pouvoir y indiquer l'adresse du NAS comme serveur principal. Sans cela, il faudra le faire au niveau des réglages des terminaux ce qui n'est pas très pratique sur des appareils nomades.

@oracle7 @Einsteinium Suite de mon souci de déploiement. Las de ne pas pouvoir déployer mes certificats à cause de ce foutu nom ignoré par le script, et après divers essais, j'ai appliqué la méthode de @oracle7 à savoir supprimer les "SAVED_" des fichiers conf des certificats. J'ai aussi changé le nom du certificat en base 64 pour le nom enregistré dans DSM. Et là, le déploiement s'est déroulé normalement. Mais ce n'est sans doute pas la meilleure approche car toutes les lignes initialement avec "SAVED_" ont été effacées dans les nouveaux fichiers conf des certificats. J'avais pris la précaution d'en faire une copie avant de les modifier, ainsi je les ai restitués dans leur état d'origine, en espérant que le problème sera résolu dans une nouvelle version d'ici le prochain renouvellement. Après réflexion, il eut été préférable que je supprime simplement les lignes des "SAVED_" et refaire les $export des valeurs avant de lancer le déploiement pour qu'elles soient à nouveau retranscrites dans le conf du certificat. C'est ce que je ferai la prochaine fois si le problème se reproduit.

Ca n'existe pas. Ce n'est pas une sauvegarde dans ce cas, c'est une synchro. Une sauvegarde une fois terminée est déconnectée de la source. Synology Drive n'est rien de plus qu'un cloud. Il ne peut pas se substituer à une vraie sauvegarde.

@Dimebag Darrell, merci de ne pas citer inutilement les posts auxquels vous répondez, ça alourdi la discussion sans rien y apporter. L'intérêt d'un serveur DNS interne c'est de pouvoir utiliser la même url quel que soit l'endroit où on se trouve, chez soi ou à l'extérieur. Par exemple, pour rejoindre Audio station du NAS, vous pouvez paramétrer le reverse proxy pour que l'adresse https://audio.ndd soit dirigée vers localhost:leport http d'audio station. A l'extérieur, les serveurs DNS redirigeront votre requête vers votre routeur qui la transmettra au NAS. Chez vous, c'est le serveur DNS local qui résoudra la même url et la dirigera vers le NAS. Mais pour que ça fonctionne, il faut impérativement que vous puissiez modifier les adresses des serveurs DNS propagées en DHCP par le routeur. Malheureusement certains routeurs n'acceptent pas ces modifications (orange entre autres). Je vous invite à voir le tuto de mise en place du serveur DNS dans la partie tutoriels.

@Dimebag Darrell le reverse proxy ne fait que le relais entre un ndd et une application. Il n'est pas lié uniquement aux accès externes. Si vous avez un serveur DNS privé (celui du NAS par exemple), il pourra faire le même exercice avec les mêmes ndd une fois résolus par le serveur DNS.

Est-ce que tu as plusieurs certificats, et si oui, est-ce que le nom du certificat a été pris en compte par le script comme ceci : SYNO_Certificate='ici le nom du certificat'

@oracle7 je n'ai aucun problème avec mes fichiers account.conf et ndd.conf, et jusqu'à la dernière version de acme.sh, tout fonctionnait parfaitement depuis des mois avec plusieurs renouvellements et déploiements. Je pense que nous avons tous les deux la toute dernière version d'acme.sh (3.0.6 deuxième jus). Malheureusement (pour moi) le renouvellement a été fait avec la première version 3.0.6 et peut-être un mécanisme a été cassé qui ne se voit pas dans les .conf. @Kramlech c'est en faite le même problème de renouvellement apparu avec la dernière version d'acme.sh. Sauf que toi, tu es reparti en cours de route sur une nouvelle install et que ça ne se passe pas correctement. Pour répondre à ton souci de clés : oui, tu peux très bien en créer de nouvelles mais si tu es sûr des anciennes et qu'elles sont toujours valides, ce n'est pas nécessaire. Tu peux vérifier ça dans la console de ton compte ovh. https://api.ovh.com/console/

@oracle7 toutes les données ont été créées avec des export exactement comme dans le github et dans le tuto. Les SAVED dans les fichiers ndd.conf et account.conf sont créés par le script. Je n'ai rien touché dans ces fichiers. Et si tu regardes le tuto, il y a bien des SAVED pour toutes les données exportées par les .conf. De même que le codage en base 64 du nom du certificat qui a été introduit par le script il y a quelques mois de ça. Là aussi je n'ai rien fait d'autre lors du premier déploiement que d'exporter en clair le nom donné dans DSM. Le script a fait le reste. Regardes la ligne SAVED_SYNO_Certificate dans mon ndd.conf, le nom en base 64 est borné __ACME_BASE64. Ce n'est pas de ma propre initiative. D'ailleurs, si tu regardes le fil de discussion du tuto, à un moment j'ai signalé ce changement du nom en dur en base 64. Et pour compléter, la conversion du texte base64 me donne bien le nom du certificat que je souhaite déployer. Lors du déploiement manuel que j'ai tenté aujourd'hui (voir ci-dessus), j'ai bien indiqué le nom du certificat en clair, mais acme.sh ne l'a pas pris en compte. Je viens d'ouvrir un sujet sur github pour ce problème.

@oracle7 merci pour cette info. J'ai ajouter le syno-create mais ce n'est pas ça. Le problème vient de la non prise en compte du nom du certificat. @Einsteinium j'ai trouvé d'où vient le problème. Le déploiement ne se fait pas car le script n'a pas pris en compte le nom du certificat. Pour le déploiement en décembre de l'un des certificats le nom est pris en compte (ligne 3) et le déploiement se fait bien : [Sun Dec 4 00:08:53 UTC 2022] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Sun Dec 4 00:08:53 UTC 2022] _cdomain='ndd.net' [Sun Dec 4 00:08:53 UTC 2022] SYNO_Certificate='Wildcard ndd.net' [Sun Dec 4 00:08:53 UTC 2022] _base_url='http://172.17.0.1:5000' [Sun Dec 4 00:08:53 UTC 2022] Getting API version [Sun Dec 4 00:08:53 UTC 2022] GET [Sun Dec 4 00:08:53 UTC 2022] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Sun Dec 4 00:08:53 UTC 2022] timeout= [Sun Dec 4 00:08:53 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:54 UTC 2022] ret='0' [Sun Dec 4 00:08:54 UTC 2022] Logging into 172.17.0.1:5000 [Sun Dec 4 00:08:54 UTC 2022] POST [Sun Dec 4 00:08:54 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Sun Dec 4 00:08:54 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:55 UTC 2022] _ret='0' [Sun Dec 4 00:08:55 UTC 2022] token='NFYYbsmbPYtng' [Sun Dec 4 00:08:56 UTC 2022] Getting certificates in Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:56 UTC 2022] _ret='0' [Sun Dec 4 00:08:56 UTC 2022] escaped_certificate='Wildcard ndd\.net' [Sun Dec 4 00:08:56 UTC 2022] Generate form POST request [Sun Dec 4 00:08:56 UTC 2022] Upload certificate to the Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=NFYYbsmbPYtng&_sid=JZY_iOUr1T19dcU5UOBsSeQFvHy94qua4IN_UVasNCwpnF9g-d1JPES5RNU9JhZgnZUtEULoix5WhifQ0pc2BU' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:09:44 UTC 2022] _ret='0' [Sun Dec 4 00:09:44 UTC 2022] http services were NOT restarted [Sun Dec 4 00:09:44 UTC 2022] Success Pour celui du 2 janvier, le nom n'est pas pris en compte (ligne 3) ce qui empêche le déploiement : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Il n'y a pas de problème dans le fichier ndd.net.conf dans le dossier ndd.net où le nom du certificat est bien indiqué en base64 : Le_Domain='ndd.net' Le_Alt='serv1.ndd.net,*.serv1.ndd.net' Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxxxxxx' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxxxxxxxxxx' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/xxxxxxxxxxxxxxxxxxxxxxxxxx' Le_CertCreateTime='1675296385' Le_CertCreateTimeStr='2023-02-02T00:06:25Z' Le_NextRenewTimeStr='2023-04-02T00:06:25Z' Le_NextRenewTime='1680393985' Le_DeployHook='synology_dsm,' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='user' SAVED_SYNO_Password='password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_' SAVED_SYNO_TOTP_SECRET='' J'ai tenté un déploiement manuel avec une tâche planifiée : $ export SYNO_Username='user' $ export SYNO_Password='password' $ export SYNO_Certificate="le nom de mon certificat" docker exec Acme sh -c "acme.sh --deploy -d 'ndd.net' --deploy-hook synology_dsm" Et là aussi le nom du certificat n'est pas pris en compte (ligne 3) : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Bref, il semblerait qu'il y ait aussi un problème au niveau du script de déploiement. Edit : Je réalise que le renouvellement du 2 février a été fait avec la première version 3.0.6 de acme.sh (celle qui a posé des problèmes à certains lors des récents renouvellements). Sa mise à jour automatique a été faite le 5 février sur ce NAS mais malgré cela, le déploiement ne se fait pas.

@Einsteinium, je viens de m’apercevoir que sur un des NAS dont je m'occupe, les deux certificats sur 2 ndd chez OVH ont bien été renouvelés automatiquement le 2 février avec pour chacun : [Thu Feb 2 00:06:25 UTC 2023] Cert success. [Thu Feb 2 00:06:25 UTC 2023] Your cert is in: /acme.sh/ndd.net/ndd.net.cer [Thu Feb 2 00:06:25 UTC 2023] Your cert key is in: /acme.sh/ndd.net/ndd.net.key [Thu Feb 2 00:06:25 UTC 2023] The intermediate CA cert is in: /acme.sh/ndd.net/ca.cer [Thu Feb 2 00:06:25 UTC 2023] And the full chain certs is there: /acme.sh/ndd.net/fullchain.cer [Thu Feb 2 00:06:25 UTC 2023] _on_issue_success mais n'ont pas été déployés avec pour tous les deux : [Thu Feb 2 00:06:26 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:06:26 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:06:26 UTC 2023] Deploy error. Voila qu'il n'arrive plus à trouver un certificat qu'il vient d'enregistrer !

@bliz, c'est pour cette raison que je disais "sans garantie", ce qui ne veut pas dire que la solution ne fonctionne pas ! @firlin d'après ce document https://global.download.synology.com/download/Document/Software/AdminGuide/Package/ActiveBackup/All/fre/Synology_ABB_admin_guide_Linux_fre.pdf à la page 21, il semblerait que le transfert vers un autre NAS soit possible via Hyperbackup Cet article peut aussi être utile : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_backup_and_relink_Active_Backup_for_Business_with_DSM_backup_packages

@bliz Normalement ce ne sont pas des fichiers hbk. @firlin Sans aucune garantie, je pense que si tu copies le contenu du dossier Active Backup for Business dans le même dossier du nouveau NAS, tu pourrais ensuite reconnecter sur le nouvel emplacement en cliquant droit sur l'icône de l'Agent sur le PC et en sélectionnant "Modifier la connexion"

@maxou56 c'est vrai et c'est aussi pour cela que le choix importe peu. Et comme il faudra tôt ou tard changer le mode de sauvegarde, autant partir tout de suite sur du Rsync pour ne pas avoir à tout refaire.

Pour ma part je dirais peu importe. Il s'agit simplement de stocker un fichier sur un support. Même si Hyperbackup Vault du NAS (213 ou 214) n'est plus compatible un jour ou l'autre avec la version Hyperbackup du 1821 (ce qui est inévitable), il sera toujours possible de consulter et restaurer les sauvegardes en passant par Synology Hyperbackup Explorer.

@Nono1333 C'est très compliqué de vous dire ce que vous devez faire car comme je l'ai dit, tout dépend des paramétrages du NAS et de ses applications. Vous seul pouvez retrouver vos besoins en consultant les réglages de DSM. Selon que vous avez ou pas un ndd chez Synology ou ailleurs, que vous avez ou pas activé le parefeu, Quickconnect, le proxy inversé, le serveur DNS, le serveur VPN, que vous avez besoin ou pas d'activer ou de rafraichir le DDNS, que vous utilisez ou pas Synology Drive ou d'autres applications nécessitant des ports spécifiques, que vous avez ou pas modifié les ports par défaut des accès au NAS, les réglages du routeur seront différents. N.B. : merci de ne pas citer inutilement les messages précédents. Ca encombre les discussions sans apporter une meilleure compréhension. Pour interpeler un intervenant, il suffit de taper la lettre '@' suivie des premières lettres du pseudo pour affiner la liste et valider le nom recherché. La personne sera notifiée de votre réponse comme vous venez de l'être pour ce message.

@oracle7 ce sont bien les réglages que j'ai fait et c'est bien comme ça que devrait fonctionner le home mode. Ce n'est pas le cas. Home mode du NAS secondaire activé par le NAS principal via le webhook, notifications de mouvement activées sur les notifications générales, désactivées dans celles du Home mode, j'ai des notifications de mouvement chaque fois que je passe devant la caméra. La seule différence, de taille, entre ta config et la mienne c'est les notifications que tu n'actives que la nuit alors que les miennes sont programmées h24/7. Ce serait intéressant que tu fasses un essai avec les notifications activées en continue pour voir si chez toi aussi tu as des notifications de mouvements en étant en home mode. Pour info, détection par caméra ou par SS ne change rien. Edit : Je pense avoir enfin compris le pourquoi des détections. Le Home mode n'agit que sur le NAS où il est activé. Il n'intervient pas sur ce qui est transmis au NAS principal via le CMS. La détection de mouvement semble être toujours active malgré le Home mode activé. Tout mouvement détecté est transmis sur le réseau et si la notification de mouvement est activée sur le NAS principal, elle déclenche un message quel que soit l'état du Home Mode de ce NAS. C'est un peu ballot comme mode de fonctionnement mais bon, il faut que je fasse avec ça. Comme mes caméras sont sur le NAS secondaire, j'ai activé les notifications sur ce NAS et je les inhibe lorsque HM est actif. Le HM de ce NAS est activé/désactivé par le HM du NAS principal via les webhook. Sur le NAS principal qui ne reçoit que les LiveCam du smartphone de mon épouse et du miens, j'ai désactivé les notifications de détection de mouvements car elles ne sont pas utiles pour ce caméras. Ca semble enfin fonctionner avec ces réglages : HM activé : pas de notifications de mouvement, désactivé : je reçois les notifications de mouvement du NAS secondaire.

Je ne comprends rien à la gestion des notifications en Home Mode. La logique voudrait que le choix fait dans les notifications du Home Mode priment sur les choix dans les notifications générales mais ce n'est pas le cas. Si je désactive les détections de mouvements dans le Home mode alors qu'elles sont activées dans le général, je reçois toujours des notifications. Le seul moyen est de les désactiver dans le général. En clair, le home mode ne présente aucun intérêt puisqu'il est incapable de faire cette chose très basique. Ce mode qui est sensé gérer automatiquement le fonctionnement de SS est sûrement une bonne idée, encore faudrait-il qu'il fonctionne, et qu'il le fasse de manière intuitive. Je me demande toutefois si le problème ne viendrait pas du fait que la détection de mouvement est gérée par les caméras et non par SS....

J'ai oublié de vous dire de d'abord commencer par donner une IP fixe à votre NAS sinon vos redirections ne fonctionneront plus lorsque le NAS changera d'adresse. Ce qui suit n'est possible que si votre NAS est en DHCP ! Si une adresse a été définie dans l'interface réseau de DSM, il faudra modifier et régler le LAN1 sur DHCP. Dans la console, vous ouvrez DHCP, onglet Baux actifs, votre NAS devrait apparaître dans la liste. Soit vous voulez conserver l'adresse déjà attribuée auquel cas il faut activer un bail statique pour cette IP, soit vous voulez attribuer une autre IP et dans ce cas, vous récupérez l'adresse MAC du NAS pour la reporter dans l'onglet Baux statique. Là vous cliquez sur Ajouter un bail DHCP statique, vous collez l'adresse MAC, vous indiquez l'adresse IP que vous voulez attribuer au NAS, ajoutez un commentaire et vous sauvegardez. Pour que le NAS prenne sa nouvelle IP, vous débranchez son câble Ethernet et vous le rebranchez.

Ca c'est toi qui le dit. As tu au moins essayé ? Moi je t'affirme que ça marche. Tu peux créer, modifier un fichier root et même définir ses droits utilisateur directement dans l'interface. Lors de la sauvegarde, il faut simplement indiquer la clé pour confirmer le status root et c'est OK. Par contre, il est bien évident qu'on ne peut pas passer des commandes dans WinSCP et qu'il faut pour cela ouvrir le terminal ou putty, tous deux intégrés dans l'interface.