Mic13710

Merci de ne pas citer inutilement le message précédent. Je viens de la supprimer. Un sous domaine n'existe pas. C'est une erreur de langage commune. Un .fr est un domaine, ndd.fr et un domaine, toto.ndd.fr et un autre domaine. Mais je vous l'accorde, c'est peut-être plus compréhensible de parler de sous domaine. Plusieurs problèmes dans ce que je vois. Tout d'abord vos règles de parefeu sont à corriger. La première et l'avant-dernière sont inutiles. C'est la dernière qui fait le boulot de refuser. La logique du fonctionnement est le suivante : le parefeu lit les règles dans l'ordre. Tant qu'une règle n'est pas applicable, il passe à la suivante. Donc, si aucune des règles en dessous de votre première règle ne passe, la dernière ligne bloquera. Vous pouvez aussi supprimer les règles concernant le port 80, elle ne sont plus applicables, Let's Encrypt ayant changé leurs IP. Je ne connais pas les nouvelles, mais lorsque votre certificat devra être renouvelé, il faudra ouvrir le port 80, au moins pour les US. Vous pouvez modifier une des deux règles pour une ouverture plus large (Tous ou les US uniquement) que vous ne validerez que pour le temps de la mise à jour des certificats. Je ne comprends rien à votre deuxième capture. Ca correspond à quoi ? Vos règles de proxy sont erronées. Vous donnez des adresse localhost en http, mais les ports que vous utilisez sont en https. Modifiez les ports de vos localhost par ceux en http que vous avez programmés dans les applications. Bien que ça fonctionne, il n'est pas utile de repasser par le https sur le localhost puisque la connexion a été sécurisée par le https du 443 jusqu'au NAS. Faire du https en interne n'a pas de sens. Les applications DS ne se connectent pas de la même manière que votre navigateur. Elles utilisent les ports par défaut de DSM. Si vous les changez, il faut alors l'indiquer dans l'adresse de connexion en la faisant suivre de ":le port à utiliser". Et comme vous passez par le reverse proxy, vous utilisez le 443 pour atteindre le NAS.

video.mondomaine.truc:443 Il est important de spécifier le port car sans cela l'application prend le port par défaut. Moi non plus je ne comprends pas votre explication. Les ports DSM par défaut sont 5000 et 5001. Vous les avez changés pour 7770 et 7771 ? Ca n'a aucune utilité mais pourquoi pas. Ensuite un port est unique. Le 443 est et reste le 443, il n'a pas d'équivalent. Vous pouvez faire une translation de port mais chaque port garde ses caractéristiques propres sur l'équipement hôte. Si vous avez dirigé le 443 vers le NAS, toute requête du WAN sur ce port sera dirigée vers le NAS. C'est ensuite le reverse proxy qui fera la distribution vers les différents services du nas ou de votre réseau en fonction du nom de domaine : file.ndd, video.ndd, audio.ndd, autredemonréseau.ndd etc...

Selon le dernier lien de maxou56, SMB direct ce n'est pas SMB1. Il y a une entrée spécifique pour ça, qui n'apparait pas dans votre tableau des fonctionnalités windows. Il y a une entrée spécifique pour SMB1, il s'agit de SMB 1.0/CIFS File Sharing Support

Pour que le serveur dns local puisse fonctionner, il faut indiquer dans le routeur l'adresse du NAS (192.168.x.x) en tant que serveur DNS principal Et il ne faut pas oublier de vider le cache du navigateur pour l'obliger à réactualiser.

Votre nom de domaine vous permet d'accéder à votre IP publique à partir du WAN. Lorsque vous êtes sur votre LAN, vous passez par l'IP privée du NAS qui elle n'est pas une URL comportant le nom de domaine. Par conséquent le certificat qui est exclusivement destiné à votre ndd n'est d'aucune utilité sur le LAN. D'où l'indication dans votre navigateur. Si vous voulez que votre certificat fonctionne aussi sur le LAN, c'est à dire que vous voulez atteindre vos services avec la même URL que ce soit côté WAN ou côté LAN, il faut utiliser le DNS Server du NAS pour séparer les zones LAN et WAN. Il y a un tuto de Fenrir dans la partie Tutoriels à ce sujet. Mais je vous préviens tout de suite, c'est un sujet qui nécessite quelques connaissances de base.

On ne vous demande pas où vous habitez, ni de décliner votre identité ou si vous mangez du foie gras tous les midis et du caviar à la petite cuillère le soir. simplement de décrire vos connaissances, votre matériel informatique, votre ou vos nas. Rien de personnel qui puisse compromettre votre vie privée. Comment croyez vous que le cloud puisse gérer les versions et vous permette de retrouver un fichier effacé s'il n'y a pas un endroit où sont stockées ces informations ? Tout ça se passe dans un fichier caché nommé @Cloudstation qui peut très vite devenir imposant si des données lourdes sont traitées dans le cloud. A supposer que vous ayez mis des films ou des photos ou tout autre fichier dans votre cloud lorsque votre nombre de versions n'était pas à 0, tous ces fichiers sont conservés sous un format propriétaire (illisible directement) dans ce fameux dossier. Et même si vous les supprimez du Cloud, ces fichiers restent enregistrés dans le dossier. Voila pourquoi, l'espace utilisé ne varie pas tant que vous n'aurez pas supprimé les historiques. Regardez aussi au niveau de vos corbeilles parce que votre espace fantôme peut très bien venir de là.

Je rajouterais que même si on passe le nombre de versions à 0, cela ne modifie pas les versions antérieures. Et donc le fichier caché reste en l'état. Il faut aller dans Cloud Station pour nettoyer le contenu de ce dossier. Et comme mes petits camarades l'ont oublié, je fais passer le message : il existe un forum dédié aux présentations pour que les nouveaux entrants nous parlent un peu d'eux. Merci d'aller y faire un tour, certains y sont sensibles.

Merci pour le retour, mais inutile de le répéter sur tous les sujets de volume planté du forum. Je déplace dans la section tutoriels et je supprime dans les sujets concernés.

C'est très simple. JBOD ou RAID0 même combat. Vous ne pouvez rien faire. Ni rajout, ni extension, ni remplacement. La seule solution est de supprimer le ou les groupes concernée(s) (ce qui de facto vous fait perdre les données) et de les recréer. Donc, si vous voulez transférer un disque d'un NAS vers un autre, ce sera sur les deux NAS qu'il va falloir supprimer. Quand on dit que ces deux formats ne sont pas une bonne idée... La meilleure solution pour transférer vos données est d'utiliser Hyperbackup qui vous permettra de restaurer vos données à l'identique et la majeure partie des paramètres. Si vous avez un DD externe suffisamment costaud, vous pouvez faire vos sauvegardes HB dessus et les restaurer à partir de ce même DD. Bon courage.

Que ça fonctionne est déjà une performance en soit car à ma connaissance seules les Freebox permettent le looopback (votre dernière description). La meilleure solution consiste à séparer les zones WAN et LAN en utilisant le serveur DNS du NAS. Vous trouverez un tuto de Fenrir dans le forum Tutoriels

Deux noms de domaine sur la même racine ou deux noms distincts ? pourquoi pas ? Si Hitman_11 veut deux URL distincts pour ses NAS, c'est une solution. Perso, j'ai deux ndd, un chez Gandi et un autre chez OVH qui pointent tous les deux sur mon IP publique. On peut en avoir autant qu'on veut finalement. Pour le reverse proxy, c'est oui. Chez OVH, vous redirigez le ndd2 vers l'IP publique (DynHost ou enregistrement A). Dans le reverse proxy, vous redirigez les ndd2 vers les différents services du nas2 (par exemple video.ndd2 vers le port http de video station, audio.ndd2 vers le port http d'audio station, etc....)

Belle présentation. Bienvenue dans la communauté. Le NAS est un excellent choix. Je suis moins certain pour les disques car faire du stockage de données, du cloud, de la vidéo surveillance, de la virtualisation plus d'autres paquets qui ne manqueront pas d'être rajoutés par la suite, il me semble que vos 2To (probablement en SHR) seront très vite occupés.

Qui vous a dit qu'il fallait faire une redirection dans le routeur ? christophe2836 vous a parlé du reverse proxy. Dans le reverse proxy du NAS1, il faut faire une règle pour rediriger le port 443 du nom de domaine nas2.votrendd (nas2 étant pris à titre d'exemple) vers le 5000 de l'ip 192.168.x.x du NAS2. Lorsque vous entrerez https://nas2.votrendd depuis l'extérieur, le routeur redirigera la requète sur le NAS1 et le reverse proxy du NAS1 renvera la requete vers le port 5000 du NAS2 ce qui vous connectera au DSM du NAS2

Attention, le dynhost s'apparente à un enregistrement A. Il doit donc être la tête du nom de domaine que vous renvoyez vers votre IP publique et celle que vous utiliserez dans la zone pour créer vos CNAME. par exemple : DynHost : toto.fr (son IP sera mise à jour par le DDNS du NAS) CNAME xxx.toto.fr utilise le ndd du DynHost pour créer un ndd qui pointera sur l'IP enregistrée dans le DynHost. Vous ne pouvez pas mettre un DynHost avec une adresse nom.toto.fr et créer des CNAME en xxx.toto.fr. Dans ce cas, vos CNAME devront être en xxx.nom.toto.fr

Est-ce que vous avez paramétré le DynHost chez OVH et est-ce que l'adresse du DynHost correspond à celle que vous utilisez pour le DDNS ?

Un petit tour par là pour commencer c'est très apprécié et ça met de l'huile dans les rouages. Vider les corbeilles peut-être ?

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.

C'est le mail que vous avez renseigné sur ovh et le mdp est celui qui vous permet de vous connecter à ovh.

Non. C'est un disque en RAID SHR. Il faut passer par une distri Linux (Ubuntu par exemple), puis installer mdadm (logiciel de raid) et lvm2 (couche multi-raid). Il y a un tuto pour ça : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC Vous pouvez fermer l'interface de DSM, pas de problème. Le NAS sait très bien travailler tout seul. Inutile de le surveiller il se débrouillera aussi bien sans vous.

C'est normal. La construction d'un groupe peut prendre plusieurs heures. Par contre, prenez garde aux secteurs défectueux. Ils peuvent poser des problèmes lors de la construction et à terme des dysfonctionnements. Après la création du groupe, faire un test SMART étendu pour commencer.

L'accès aux dossiers cachés se fait uniquement par ssh ou telnet via une console. Si vous ne maitrisez pas les lignes de commandes, mieux vaut éviter. Faites un transfert de vos données des 4To vers les 6To (je suppose que ce n'est pas la place qui manque). Utilisez la fonction de déplacement dont j'ai parlé plus haut. Quand c'est fait, vous sortez les deux 4To et vous les formatez sur un pc (formatage rapide), puis vous les réinstallez pour recréer votre groupe et votre volume. Vous faite l'opération inverse pour les dossiers transférés précédemment. Les 4To étant votre volume 1, les paquets s'y trouvent par défaut et seront alors éliminés, ce qui résoudra votre problème. Il va falloir ensuite réinstaller tous les paquets.

Les paquets sont installés par défaut sur le volume 1. Vu la méthode employée, vous avez probablement cassé des processus, ce qui cause les erreurs sur les paquets. Non, les paquets n'occupent pas 1To. Comme je l'ai dit, ce sont les dossiers cachés qui occupent l'espace. Ces dossiers sont gérés par les paquets mais peuplés par les données. Pour pouvoir supprimer un volume, il faut d'abord arrêter les paquets à partir du gestionnaire des paquets. Pour les données restantes sur les 2To, si ce sont des dossiers partagés, vous pouvez tout simplement modifier leur emplacement vers l'autre volume directement à partir du Panneau de configuration - Dossiers partagés. En modifiant le volume d'emplacement, le dossier et son contenu seront transférés. Il faudra attendre la fin du processus.

Ce dont je parlais c'est de la restauration des données à partir d'un dossier .bhk situé sur un disque externe. Pour ce qui est de la migration d'un dossier .bhk, c'est aussi possible. Si vous copiez un dossier toto.bhk de votre DD externe dans le dossier de sauvegarde du NAS cible, vous pouvez recréer une tâche dans Hyperbackup du nas de départ en vous reconnectant sur une tâche existante qui pointe vers le dossier toto.bhk. Toutes les versions qui existent dans ce dossier sont reprises à l'identique par Hyperbackup et seront prises en charge dans Hyperbackup Vault dès la première mise à jour de la sauvegarde.

Sur ce forum, on aime bien que les nouveaux arrivants passent par la section des présentations. Ca permet de mieux vous connaitre, connaitre votre matériel et savoir quel est votre niveau. Effectivement vous n'avez pas du tout suivi la bonne méthode pour effectuer votre migration. C'est probablement la pire qu'il m'ait été décrite. C'était avant d'agir qu'il aurait fallu venir nous voir. Maintenant, il est trop tard. Ce qui reste sur vos disques correspond à des dossiers cachés de certains paquets comme Cloud Station (ou Drive), download station et autres. Si vos données sont sauvegardées et que vous pouvez les restaurer, vous pouvez tout simplement supprimer votre volume puis le recréer. Cette opération supprimera tout le contenu des partitions de données. Le formatage des disques est inutile.

Il est tout à fait possible de restaurer des fichiers hyperbackup à partir d'un disque externe. Sur Hyperbackup du NAS distant, vous cliquez sur le bouton de restauration des données. Dans la page qui s'ouvre vous cliquez sur "Restaurer à partir des référentiels existants", puis vous choisissez Dossier local est USB. La suite est évidente.