.Shad.

Salut, Pour de la sauvegarde, je les utiliserais en basic. Le SHR permet d'avoir soit une continuité de service (équivalent RAID 1 ou 5), soit un gain de performance en lecture écriture (équivalent RAID 0). À mon humble avis, aucun des deux modes n'est utile pour une sauvegarde. A voir ce qu'en disent des utilisateurs plus avertis concernant le stockage : @maxou56

A ma connaissance, le profil de contrôle d'accès que tu configures dans le proxy inversé s'applique uniquement à Nginx, pas Apache. C'est dans Webstation que tu peux gérer des virtual hosts et des profils de contrôle d'accès. Pour ma part, pas d'autre idées...

DSM fournit une UI pour son paquet Docker qui est effectivement limitée. Mais en ligne de commande sur le Syno tu as accès exactement aux mêmes fonctionnalités que le permet une quelconque distribution Linux (que ce soit Docker directement ou Docker-compose). L'image a l'air bien maintenue : https://hub.docker.com/r/prestashop/prestashop/ Personnellement, mes applications Docker, qu'elles soient sur le NAS ou sur une autre machine, utilisent l'instance MySQL native de DSM. L'un n'empêche pas du tout l'autre.

@ewfzapp Pour info, pour que QuickConnect fonctionne correctement, il est recommandé d'activer l'uPnP sur le routeur/box. Le principe de QuickConnect est justement de faciliter l'accès au NAS si on ne veut pas faire de configuration manuelle, et donc les outils qui le permettent doivent être actifs. Maintenant que ça a été dit, je rejoins tous les autres, si tu es un minimum concerné par la sécurisation des données de ton NAS, je te conseille de le désactiver et de mettre en place un accès distant ou VPN. 😉

Comme dit sur d'autres sujets, les images postées par Fenrir sont hébergées sur son NAS, et sont donc inaccessibles lorsqu'il est hors ligne. On a plusieurs fois évoqué la possibilité d'éditer son tutoriel et les transférer sur le forum directement. Mais rien n'a bougé de ce côté-là pour le moment, ce sont les modérateurs qui doivent s'en charger.

Je reviens sur ce que j'avais proposé (mettre 127.0.0.1 en 2ème IP). Le profil de contrôle d'accès c'est bêtement une interface pour le système d'ACL intégré à Nginx. Si tu mets juste l'IP d'un périphérique qui n'est pas le NAS (ce que tu sembles vouloir faire), comment le NAS lui-même accède-t-il à Nginx ? Il ne peut pas. Le plus simple est donc de mettre 127.0.0.0/8 en adresse autorisée. Ainsi tu es sûr que le NAS pourra toujours accéder à son proxy inversé, car c'est par la boucle locale qu'il essaiera de travailler par défaut. En revanche, si tu me dis qu'en ajoutant uniquement les IP d'un PC A et B en autoriser, que tu refuses tout le reste, et que ça fonctionne correctement (OK pour ces deux périphériques, NOK pour le reste), je t'avoue que je n'y comprendrais plus rien et pencherais pour un bug.

@Juan luis avoir un serveur VPN sur son NAS n'empêche aucunement d'y accéder à distance. Le NAS a juste une interface avec son IP de serveur VPN, une interface avec son IP locale, et tu y accèdes via NAT sur ton routeur ou ta box. Ou je n'ai pas compris le sens de ta remarque.

C'est dans les paramètres du serveur DHCP que tu dois indiquer l'IP du NAS en tant que Serveur DNS primaire (ou principal).

Bienvenue parmi nous ! On a de la veine de t'avoir !

Si c'est ce que je pense ce n'est pas un bug, c'est normal. Est-ce que l'autre IP 192.168.... que tu as testée c'est celle du NAS ?

Bienvenue !

J'ai une idée mais je suis pas du tout devant mon PC pour vérifier. @Kramlech Quand tu ajoutes l'IP seule, ajoute aussi 127.0.0.1 Et reteste si ça marche.

Bienvenue parmi nous 🙂

Hier j'ai eu le centre de paquets inaccessible pendant une heure environ, aucune idée pour la partie assistance.

Bienvenue parmi nous !

Bah ça dit juste que le renouvellement se fera le 16 juillet pas avant, donc c'est bon. Avantage notable de ZeroSSL par rapport à Let's Encrypt : plus de limite hebdomadaire de demande de certificat.

192.168.0.0/24 ça veut dire que tes IP vont de 192.168.0.1 à 192.168.0.254, vérifie que ton réseau est bien en 0.x 172.16.0.0/12 c'est pour Docker dans DSM. Le sous-réseau VPN dépend du serveur VPN que tu utilises, sur le NAS avec PPTP, L2TP/IPSec ou OpenVPN, ou sur une autre machine de ton réseau, sur un réseau quelconque. Tu es seul à avoir cette info. 😉

Dans ce cas-là tu as par exemple nas.hurion.ovh, nas2.hurion.ovh, vps.hurion.ovh, etc... Tu crées un certificat pour chacun des domaines ci-avant, et tu crées par exemple files.nas2.hurion.ovh, music.nas.hurion.ovh, wordpress.vps.hurion.ovh, etc... Mais si ce domaine est destiné uniquement à accéder à des applications derrière une même IP publique, je pense que tu peux t'en passer. Comme l'a dit @PiwiLAbruti tu crées un dynhost du type dynhost.hurion.ovh (pas besoin d'ajouter l'info que ça pointe sur un NAS), puis tu crées tes entrées qui amènent derrière l'IP publique vers laquelle pointe le dynhost : dsfiles.hurion.ovh, dsaudio.hurion.ovh, etc... Pour apporter une nuance à ma première phrase : Tu peux le contourner en transformant files.nas en files-nas par exemple. 😉

@Mic13710 Alors je viens effectivement de vérifier l'histoire des niveaux, en effet tu as raison. Le * de *.ndd.tld n'est valable que le 1er niveau. Donc oui : @HugOil Tu remplaces l'enregistrement : *.hurion.ovh CNAME nas.hurion.ovh par : *.nas.hurion.ovh CNAME nas.hurion.ovh Et tu t'assures que ton dynhost nas.hurion.ovh pointe bien sur ton IP publique (déjà le cas a priori). Comme je t'avais dit de faire, le nslookup fonctionnait mais tu aurais eu un problème avec ton certificat. Il te faudra demander un certificat pour nas.hurion.ovh au lieu de hurion.ovh C'eût été plus simple si tu n'avais pas choisi deux niveaux de sous-domaines pour tes entrées de proxy inversé, mais soit. Le nslookup fonctionnera aussi, et logiquement si tout le reste est bien configuré tu devrais arriver sur tes différentes applications au travers du proxy inversé. Réponse ne faisant pas autorité c'est normal, c'est la box ton serveur DNS et c'est elle qui répond, et ce n'est pas elle qui héberge ta zone DNS (mais OVH par défaut) donc ça te précise juste qu'elle ne fait pas autorité sur ce domaine.

@Mic13710 Oui, par exemple dans ma zone OVH : J'ai ajouté un enregistrement wildcard pour l'occasion pour le test, résultat : Tu n'as pas besoin de descendre un niveau en dessous du dynhost. Je pense que tu confonds avec le fait que tu avais demandé deux certificats wildcard pour un nas1.ndd.tld et nas2.ndd.tld, et que du coup tes enregistrements étaient de la forme *.nas1.ndd.tld et *.nas2.ndd.tld, j'ai toujours été étonné que faire un seul et même certificat ne puisse pas fonctionner, car un wildcard ça veut dire ce que ça veut dire, ça représente tous les caractères acceptables, le point (.) compris. Mais en tout cas ici il peut rester sur un sous-domaine (et pas un sous-sous-domaine, si je peux m'exprimer ainsi).

Ca c'est bon. Tu supprimes tout ça : Je viens de le faire dans OVH, est ce bien comme ça? Mais ouvrir nas.hurion.ovh n'ouvre pas par défaut tous les sous-domaines dessous (file.nas/audio.nas etc...)? Le problème c'est que sur mabox, je ne peux activer qu'un seul DynDns. Est ce que la solution c'est de mettre *.hurion.ovh dans le nom de domaine? Mais le DNS ne semble plus fonctionner car dans le DynHost d'OVH quand je rafraichi, il ne retrouve pas mon IP. En revanche si je mets nas.hurion.ovh dans Nom de domaine, le Dynhost nas.hurion.ovh retrouve bien l'IP mais pas les autres. Un peu perdu... Tu ne gardes comme dynhost que nas.hurion.ovh, et t'assurer qu'il est fonctionnel (renvoie ton IP). Tu peux très bien utiliser aussi le client DDNS de ton NAS. Normalement après ça le nslookup devrait renvoyer ton IP publique.

Sur le principe oui, mais tu utilises un dynhost pour te connecter chez toi (nas.hurion.ovh) car j'imagine que tu as une IP dynamique. Donc ce n'est pas vers hurion.ovh que ton CNAME doit pointer, mais vers nas.hurion.ovh Evite de mettre un TTL de 0 pour tes CNAME, met au moins 3600, voire plus, genre 86400. PS : hurion.ovh pointe sûrement par défaut vers l'IP que propose OVH à l'établissement de la zone DNS, c'est un hébergement gratuit chez eux, tu peux laisser ainsi.

Parce que j'ai hacké ton PC. Jolie coupe d'ailleurs. 😶 Plus sérieusement, les IP privées ont des sous-réseaux réservés : - 192.168.0.0 à 192.168.255.255 - 172.16.0.0 à 172.31.255.255 - 10.0.0.0 à 10.255.255.255 198.x.y.z serait une IP publique. Sinon pour ton problème on voit que le domaine n'existe pas, ça veut dire que tu n'as pas créé d'entrée A ou CNAME dans ta zone DNS OVH. Donc il faut y remédier. Et t'assurer ensuite que ton certificat Let's Encrypt couvre ce sous-domaine quand tu le crées (depuis ton NAS j'imagine ?).

A priori c'est bon pour la redirection. Depuis l'invite de commande MS-DOS de Windows, peux-tu taper : nslookup files.nas.hurion.ovh 192.168 a priori, pas 198.

Est-ce que tu as redirigé les ports de la box vers le NAS ? Sinon ta requête s'arrêtera sur la box.