CoolRaoul

L'objet de mon post était essentiellement de corriger les inexactitudes du *tuto* (et c'est d'ailleurs surtout son contenu que j'ai cité), en particulier l'indication du choix de l'option "SFTP" dans le profil WinSCP au cas ou d'autres auraient voulu l'appliquer tel quel. Au passage j'en ai profité pour en souligner ce qui était inutile et faire quelques suggestions d'amélioration de "confort" (Pageant). Ca peut toujours faire gagner du temps à certains. J'entend bien que ça ne t'es sans doute pas utile personnellement mais ça peut servir à d'autres, et donc pourquoi s'en priver? (on est dans un forum public après tout) Au passage j'en ai profité pour donner ce que je pense être l'explication de l'anomalie signalée: "putty subit un refus de clé, mais winSCP fonctionne!". L'ayant qualifié d'"étonnant", ca donnait l'impression que que ça attendait une réponse. Au temps pour moi.

Pas besoin de "client" ftp, c'est intégré à filestation: Outils -> "connexion à distance" -> "configuration de la connexion" -> FTP Ensuite suffit de faire des copier/coller ou des drags & drop.

Je ne vois pas comment cela peut marcher: il n'est pas possible de se connecter "root" à DSM (et ça ne date pas de DSM6) en utilisant SFTP (SSH ou SCP ok par contre si on a bien enregistré la clé publique dans ~root/.ssh/authorized_keys) L'utilisation de cette option "allow the connection agent" présuppose qu'on utilise l'agent (pageant téléchargé avec putty) alors que le tuto n'en parle pas. De plus dans ce cas, il est inutile de spécifier de "private key file" dans Auth parameters. Inutile de préfixer ce "vi" (ainsi que les suivants) de "sudo" étant donné qu'on est *déjà* root (de part le "sudo -l -U root" précédent) C'est normal que ca ne fonctionne pas en SFTP : DSM ne supporte pas les connexions root dans ce mode. Si Putty échoue avec un refus de clé c'est que le chemin du fichier de clé privé spécifié dans sa propre configuration de session (Connexion -> SSH -> AUTH -> "authentication parameters") est erroné ou manquant. Mais je te conseille d'utiliser Pageant. Lancé au démarrage de ta session windows, on y charge la clé privée et ensuite plus besoin de retaper sa passphrase jusqu'au prochain login (s'assurer pour cela que dans putty Connexion -> SSH -> AUTH -> "authentication methods", "attempt authentication using pageant" est coché))

Les étapes 8 à 10 ci dessus sont inutiles: traditionnellement, les options en commentaire dans le sshd_config pré-installé n'ont d'autre rôle que de documenter les options par défaut. Les dé-commenter ne change donc rien

Si l’adresse ci dessus est bien un copier/coller et pas une IP au hasard donnée à titre d'exemple, c'est que contrairement à ce que tu penses, l’accès internet entrant à ton NAS est bien ouvert. 59.45.79.21 est une IP chinoise: https://www.abuseipdb.com/check/59.45.79.21 et tu n'es pas le premier auquel quelqu'un derrière cette adresse tente de s'attaquer: https://www.abuseipdb.com/report-history/59.45.79.21 Vérifie ici si le port 22 est ou pas fermé chez toi. Te restes à suivre les conseils de @Fenrir

Le reverse proxy Nginx est entièrement indépendant du type de serveur choisit dans DSM vu qu'il s'agit d'un front-end: il utilise notament son propre process et ses propres ports TCP.

Quickconnect n'utilise que des connexions TCP *sortantes*, et c'est justement le but de cette méthode, pas besoin de rediriger de ports dans le routeur, que ce soit en dur ou par UPNP. Par contre certaines Livebox (toutes?) implémentent un firewall dont un des mode est assez strict vu qu'il filtre également les flux *sortants*: http://assistance.orange.fr/livebox-modem/toutes-les-livebox-et-modems/installer-et-utiliser/piloter-et-parametrer-votre-materiel/le-parametrage-du-firewall-de-votre-livebox/livebox-2-parametrer-le-firewall_21365-21836 Je conseille d'aller vérifier si ce dernier ne serait pas en niveau de sécurité "élevé".

je suppose que tu as lu le fil Let's Encrypt et DSM 6.0 : comment créer et installer un certificat sur votre NAS Synology et en particulier le post de @warkx: http://www.nas-forum.com/forum/topic/50375-lets-encrypt-et-dsm-60-comment-créer-et-installer-un-certificat-sur-votre-nas-synology/?do=findComment&comment=1319290327

Désolé, je n'ai pas d'autre piste pour le moment.

Dans ce cas la manip n'est bien entendu pas nécessaire. Juste s'assurer que ton serveur est bien accessible de l'extérieur avec ton nom de domaine perso.

Je ne comprend pas ce qui te poses problème: pour qu'un certificat SSL let's encrypt serve à quelque chose, faut que ton NAS soit accessible de l'extérieur en HTTP(S). Mais si tu ne sais pas comment faire, pour quelle raison as-tu besoin d'un certificat alors? **EDIT** Pour que la création de certificat fonctionne, faut que http://<nom_du_nas>.<ton_domaine>.ext aboutisse sur ton Synology.

Me semble me souvenir qu'il est nécessaire d'avoir redirigé les ports HTTP dans la box ou le routeur (443 et peut-être aussi 80) pour que ça fonctionne (uniquement le temps de l'opération,on peut refermer ensuite)

Dans FileStation, créer un dossier de réception (n'importe où, c'est sans importance) Ensuite, bouton droit -> "créer une demande de fichier" Renseigner les champs l'URL générée de partage est copiée dans le presse papier (sinon suffit de la récupérer dans le champ "lier") Communiquer cette URL à vos amis Il faudra vérifier que le port 5000 est correctement redirigé dans la box/le routeur (ou le 5001 pour une connexion sécurisée SSL, faudra aussi modifier le port dans l'url récupérée ci-dessus, mais ce n'est pas indispensable ici). Ou bien, si on ne veut pas avoir à s’embêter avec ça, configurer Quickconnect: panneau de configuration -> "quickconnect" -> avancés -> cocher "partage de fichiers"

S'agit d'un problème assez répandu constaté par ceux qui utilisent la fonction "configuration du routeur" (anciennement "EZ-Internet") ce qu'on a toujours ici dans le forum déconseillé. Il est bien plus fiable de faire les redirections de ports dans la box, d'autant plus avec une Freebox ou l'interface est assez bien conçue. D'autres témoignages récents: DSM 6 erreur "vérification de l'environnement reseau" autour d'EZ-Internet (invisible dans "paquets", fiabilité, éviter?) En résumé mon conseil est: dans "configuration du routeur", tout supprimer ce qui a été configuré redémarrer Freebox, NAS et PC configurer les redirections de ports en allant sur http://mafreebox.freebox.fr/ -> paramètres de la Freebox -> gestion des ports -> redirections de ports

Soyez indulgents: ne trouvez-vous pas quand même un peu WTF de lire dans le même message "erreur inconnue" pour en découvrir, juste en dessous, sa cause, en totale contradiction avec la qualification "inconnue".

3 ans 4 mois 18 jours

La manip fonctionne mais nécessite bien entendu que SSH soit activé, contrairement à ce que pourrait laisser entendre la phrase ci dessus.

Ca serait cool que ca marche car mon workaround n'est pas top compatible avec Tapatalk (les sauts de lignes passent à l'as) Super (j'avais même pas remarqué que copier/coller avait disparu car j'utilise spontanément le clavier pour ça)

Ah dans le cas de la sauvegarde de NAS à NAS je ne saurais donner le méthode pas à pas: je ne l'utilise pas. Faudra sans doute passer par le rsync "héritage", mais ensuite, vu que je je n'ai pas utilisée faut expérimenter. C'est la sauvegarde disque à disque de type "mirroir" qui me manquait

C'est dans les notes de version, ici: https://www.synology.com/en-us/releaseNote/HyperBackup

C'est désormais résolu: depuis sa dernière version qui vient juste de sortir, HyperBackup sait également effectuer des sauvegardes avec l'ancienne méthode. J'ai évoqué cette nouveauté ici pas plus tard que ce matin:

Ce qui arrive en effet c'est qu'on ne voie plus par moment le serveur NAS dans le "voisinage réseau" (en particulier si on n'a pas utilisé d'IP statique pour ce dernier, il y a d'ailleurs belle lurette que je n'utilise plus cette approche pour accéder à un serveur). Par contre l'utilisation directe de chemins UNC fonctionne aussi bien (plus particulièrement quand ça ne fonctionne pas le problème est plus grave et dans ce cas les dossier mappés ne marchent pas non plus). Un raccourci sur le bureau (ou ailleurs) vers le NAS (nouveau -> raccourci -> \\<nom_du_nas>, ou, encore plus fiable, "\\<ip_du_nas>") est aussi une autre possibilité. Enfin bref chacun fait comme il veut, je conseille juste ce que d'expérience je considère comme le plus souple (savoir aussi que les dossiers mappés sont liés au compte utilisateur Windows, si on change de compte faut tout déclarer)

Faudrait considérer l'un des deux fils de discussion comme définitivement clos, on va attraper une migraine en continuant à alterner les questions et les réponses la-bas et ici

Les deux méthodes utilisent le même protocole et sont donc fonctionnellement équivalentes. L'approche mappage est plus une survivance historique et peut encore s'avérer utile pour les applications (de plus en plus rares heureusement) qui ne savent pas gérer les noms de fichiers au format "UNC" ("\\serveur\partage\chemin\nom") Dans tous les autres cas, la méthode que tu utilises est celle que je conseille (en ne négligeant pas la possibilité d'ajouter des raccourcis aux dossiers les plus souvent utilisé dans la zone "favoris" de l'explorateur.)

Avec cette commande tu reste admin pas root (se constate au prompt). La bonne commande est sudo -i Et ensuite pas besoin de "sudo" devant le "chown" (et pourquoi avoir tapé "nomadmin" ? tu as un compte "nomadmin"?) Sinon, le mieux est de se référer au tuto que j'ai donné dans cet l'autre fil : (c'est pas pratique d'avoir deux fils ouverts sur le même sujet)