Mic13710

@Varx bravo pour le tableau récapitulatif. Du coup je l'ai placé en recommandé pour que chacun puisse aller directement le consulter. Il y a cependant un oubli concernant le 713+. La Kingston KVR13S9S8/4 RAM 4Go 1333MHz DDR3 Non-ECC CL9 SODIMM 204-pin, 1.5V est compatible. Et je peux le confirmer puisque c'est celle qui est installée sur mon 713+ et qu'elle fonctionne sous dsm6 et 7. Merci de la rajouter au tableau.

Cela dépend des modèles. Sur les pack de 5 il n'est pas fourni. Sur les unitaires oui. Il y a aussi UAP-AC-PRO qui se situe entre le LITE et le LR.

Bien vu maxou56. Du EXT4 sur un NAS compatible BTRFS, ça fleure bon la migration et son cortège de limitations, notamment sur le volume.

Les switchs des box ne sont pas très performants et il est de loin préférable et même recommandé d'utiliser un switch externe dédié. Bien évidemment, il faut privilégier les solutions câblées plutôt que le Wifi (votre point 1). Mais si vous pensez obtenir avec une liaison filaire 1Gb la même performance qu'un disque interne, vous pouvez d'ore et déjà oublier. La seule solution approchante serait de passer au 10Gb ou à la rigueur au miltigig (2.5Gb), ce qui n'est pas actuellement disponible sur aucun des NAS Synology. Le 10Gb est possible sur certains NAS à condition d'y adjoindre une carte réseau, et il faut bien entendu que tout le réseau entre le PC et le NAS suive et soit capable de supporter le 10Gb.

Oui mais dans ce cas, on peut très bien n'utiliser que le SHR1 sur chaque unité, ce qui revient à avoir 2 disques de tolérance de panne répartis sur 2 groupes. Quelle que soit la configuration, il faut de toute façon avoir une sauvegarde régulière des données, au moins les plus sensibles. Car je le répète, le RAID n'est pas une sauvegarde mais seulement une continuité de service.

C'est normal puisque le 12To ne peut pas être associé à un autre disque de taille équivalente pour former un RAID1. Seuls 4To peuvent être associés aux 4To existants. Les 8To restants ne sont pas utilisables et sont en attente d'un autre 12To pour être intégrés au groupe.

Oui. Mais sachez que plus vous rajoutez des disques à votre groupe, plus vous augmentez les risques de perte du dit groupe lors de reconstruction ou d'extension. Le pourcentage de risque augmente de manière exponentielle en fonction de la taille des disques et de leur nombre. Je n'ai pas les chiffres en tête mais on les trouvent sur internet. Concernant l'extension d'un groupe sur l'unité externe, comme @maxou56 je ne suis pas très rassuré par ce type de configuration car si l'extension tombe en panne (défaillance de son alimentation, autre) il peut y avoir de grands dommages au groupe (perte de synchronisation) qui peuvent conduire à la perte totale du groupe. Perso, je suis plus dans l'optique de "un appareil, un groupe".

Je ne comprends pas pourquoi vouloir faire un reset. Si vos disques ont été formatés, vous êtes parti sur une installation neuve. Hormis la version de DSM inscrite dans l'eprom, il ne reste rien de la configuration précédente. Pour la question du bip sur le reset de deuxième niveau, je ne sais pas vous dire le pourquoi. Il se peut que le switch soit HS. Est-ce que le premier niveau fonctionne ?

C'est donc une installation neuve. Voir ce tuto : Attention toutefois, DSM7 n'est pas directement accessible pour le 214+, du moins pas à partir de DSM6.2. Il faut charger le .pat manuellement. Mais il est possible que lors d'une installation neuve, Synology Assistant propose directement DSM7. Mais si la version de DSM de l'installation précédente est inférieure à la 6.2, il faudra peut-être passer par des versions intermédiaires avant d'arriver à DSM7. Voir ce que proposera Synology Assistant. pas compatible avec le 214+

@.Shad. Fais le test badblocks jusqu'au bout, histoire d'isoler les secteurs défectueux. Même si le disque n'est plus aux standards requis pour le NAS, tu peux bien évidemment l'utiliser pour d'autres applications, par exemple dans un boitier externe pour des sauvegardes.

@oracle7, @Phenix21 a raison, c'est un autre sujet qui doit être abordé sur un fil dédié. Celui-ci est déjà bien assez chargé, inutile de l'encombrer encore plus

Je suppose que votre DSM est en 6.2 La suite Drive n'est pas compatible avec votre NAS. Il faut utiliser CloudStation qui est compatible jusqu'à la dernière version (4.3.3-4469). lien de téléchargement pour votre NAS : https://global.download.synology.com/download/Package/spk/CloudStationServer/4.3.3-4469/CloudStationServer-armv5-4.3.3-4469.spk Le client Drive n'est plus compatible avec CloudStation depuis la version 3. Il faut utiliser le client en version 2. Lien de téléchargement selon votre système : https://archive.synology.com/download/Utility/SynologyDriveClient/2.0.4-11112 Vous pouvez aussi utiliser le dernier client CloudStation : https://archive.synology.com/download/Utility/CloudStationDrive/4.3.3-4469 Edit : Je viens de supprimer votre demande en doublon sur un autre sujet. Par ailleurs, il est d'usage sur ce forum comme sur beaucoup d'autres de passer par la section des présentations avant de poster. Certains y sont sensibles. Il n'est pas trop tard.

Il faut dans ce cas diriger domaine.tld vers le 918. Dans votre zone DNS, vous faite pour domaine.tld soit un enregistrement A si IP publique fixe, soit un DynHost si IP dynamique qui pointe vers l'IP publique du 918. Vous rajoutez un CNAME de domaine.tld pour le ns1.domaine.tld, et je suppose qu'il vous faudra un autre CNAME pour *.ns1.domaine.tld pour les domaines du reverse proxy. Vous rajoutez ensuite tous les enregistrements MX etc.. pour votre serveur mail sur domaine.tld

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.

Non mais je rêve ou quoi ? DSVideo est une interface pour lire des vidéo. En aucun cas elle permet de contourner des droits d'auteur s'ils existent et je ne comprends pas comment il pourrait en être autrement. La réponse ayant été apportée, je clôture ce sujet.

Est-ce que quand vous tapez https://dsm.****.ovh en local vous arrivez à vous connecter ? est-ce que la plage 10.0.0.0/255.0.0.0 est autorisée dans le parefeu ?

Je n'ai pas dit qu'il ne fallait pas faire de réservation d'IP, c'est même fortement recommandé. Mais la réservation ne doit se faire que pour le réseau local. Or, il me semble que vous tentez de faire une réservation sur le réseau local d'un équipement distant ce qui bien évidemment ne peut pas fonctionner. Pour ce qui est des plages DHCP, lorsque vous lancez une requête et que vous êtes connecté en VPN sur un autre réseau, la recherche va d'abord se faire sur le réseau local. Si l'adresse existe, le routeur vous connecte au périphérique qui répond à la demande et la recherche s'arrête. Ce n'est que lorsque la recherche n’aboutit pas en local qu'elle va s'étendre au réseau distant. Si vous avez par exemple une adresse locale 192.168.1.10 et que vous avez la même adresse pour un périphérique distant, vous ne pourrez jamais atteindre ce dernier parce que son adresse existe aussi en local. C'est pourquoi il faut que vos réseaux, local et distant, ne soient pas sur la même plage pour pouvoir joindre tous les appareils connectés aux deux réseaux.

@Flo51 ce que vous dites là est inquiétant. Dois-je comprendre que vous n'avez pas de sauvegardes régulières de vos données et que vous comptez sur la fragilité d'un RAID0 pour les stocker ? Après, hyperbackup ou sauvegarde traditionnelle, peu importe, c'est à vous de choisir la méthode qui vous convient le mieux. Il vous faut de toute manière repartir de zéro.

Non. Si le premier disque constituant le SHR fait 6To, vous ne pouvez pas y rajouter des disques de capacité inférieure. Seulement des 6To ou plus. Et non pour le RAID0 de la deuxième question : le SHR est un RAID hybride qui combine basic, RAID1 et RAID5. En règle générale, le RAID0 ou le JBOD doivent être construit avec l'ensemble des disques. Ils ne peuvent pas évoluer par la suite.

@dom2 sous DSM7 : portail de connexion, onglet Avancé, bouton Proxy inversé

Je suis d'accord. Néanmoins, je suis dubitatif devant les résultats car quand je vois seulement 50h d'utilisation, ça me laisse perplexe. Ce disque est-il neuf ?

C'est là amha que se situe l'erreur. La réservation étant faite sur le réseau local pour une adresse sur le réseau distant, il est impossible de pouvoir se connecter. Une règle de base essentiel en matière de VPN c'est d'avoir des plages DHCP différentes pour chaque réseau pour éviter d'avoir des adresses distantes qui ne peuvent pas être résolues parce que déjà existantes sur le réseau local. Éviter les trop courus 192.168.0.x, 192.168.1.x mais prendre plutôt des plages du genre 192.168.w.x ou w peut prendre ce qu'on veut entre 2 et 254. Il faut bien entendu que w soit différent entre le réseau local et le distant.

Ah je vois, adepte du SM ! quand on aime... 😉

Toi tu cherches les ennuis. Pourquoi te faire tant de mal ? C'est de l'auto flagellation ! Au fait, est-ce que le ER-X sait gérer l'IPV6 ?

OK, merci pour le retour. Je vais considérer l'histoire du certificat unique pour les deux domaines de mon frère. Par contre, je vais garder l'API commune qui est moins compliquée à gérer. De mon côté, j'ai un ndd chez ovh et un autre chez gandi. Pas d'autre choix dans ce cas de faire un certificat par registar car le script de demande n'est pas le même (dns_ovh et dns_gandi_livedns), mais là aussi je les crée sous une seule instance docker. Le account.conf contient alors les deux API : SAVED_OVH_AK='xxxxxxxxxxxxx' SAVED_OVH_AS='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' SAVED_OVH_CK='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' GANDI_LIVEDNS_KEY='xxxxxxxxxxxxxxxxxxxxxxxxxxx'