.Shad.

Bienvenue parmi nous !

C'est l'un ou l'autre.

Il n'y a pas de différence de comportement, que ce soit directement en ligne de commande (docker) ou via docker-compose, à vrai dire la version graphique de DSM n'apporte aucun avantage par rapport à ce que permet Portainer si tu veux une interface graphique. L'avantage de Docker, quelque soit la méthode, c'est que ça survit à toutes les upgrades (sauf si l'implémentation de Docker sur DSM est cassée, évidemment). Docker-compose permet de créer des volumes, des réseaux, des ordres de démarrage ou d'arrêt, etc... à la volée. Et lorsque tu arrêtes ou supprimes une stack, docker-compose s'assure de suivre toutes ces étapes. Quand tu passes par DSM, si tu arrêtes un conteneur, ça revient à faire un bête stop, donc tu bypass tout ce que tu aurais pu prévoir dans ton fichier compose. Portainer devrait pouvoir te donner toute satisfaction, tu peux trouver un guide d'installation ici : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/

Pourquoi https://localhost:3001 pour le proxy inversé. Le port 3001 n'est mentionné nulle part ailleurs, tu voulais pas dire 3000 ? Et pourquoi https ? Adguard s'expose par défaut sur un port sécurisé ? Autre chose, pour l'écriture en octet pour la mémoire dans docker cli, tu peux utiliser le "M" pour mega. Donc 128Mo -> 128M. Merci pour le tuto sinon, je testerai un jour pour comparer avec Pihole.

Bienvenue parmi nous !

Par défaut ça te sauvegarde la configuration du NAS, donc le paramétrage. Pour les applications, c'est une étape de la création de la tâche de sauvegarde. Tu peux modifier la tâche et vérifier ce que tu lui as demandé de sauvegarder.

Est-ce que tu utilises un DDNS ? Tu peux vérifier via nslookup ndd.tld (remplacer par ton nom de domaine devenu non fonctionnel) depuis PowerShell pour voir ce que ça renvoie.

Merci ça fait toujours plaisir à lire, même si je vais sûrement l'améliorer (surtout la partie docker-compose qui est trop superficielle). A priori Diun a besoin de monter le socket dans tous les cas. C'est la meilleure méthode pour Pi-Hole, mieux que Docker selon moi. Bravo ! Oui ça peut marcher ainsi, c'est ce que j'utilise pour établir un tunnel SSH via VPN depuis un NAS distant vers mon réseau local. Je fais ça car le NAS est derrière un pare-feu entreprise et que je n'ai pas accès au SSH sinon, et donc que le seul moyen d'y avoir accès c'est que lui initie une connexion vers l'extérieur. Tu devrais faire la même tâche avec down au lieu de up -d. 😉 Personnellement quand SSH est dispo je m'en sers. 🙂 Ca t'informe du changement d'état des conteneurs, pour l'instant j'ai juste eu l'information si un conteneur s'arrête de manière inappropriée, c'est le cas selon DSM quand Watchtower fait sa ronde de mise à jour.

Re-Bienvenue !

Welcome !

Bienvenue parmi nous !

Bienvenue parmi nous !

Ce problème n'est pas contournable avec Drive. Drive ne fait pas un tampon local comme tu sembles le penser, c'est une synchronisation entre le NAS et un client. Tu as donc réellement une version du fichier sur ton client. Et cette version n'est pas une version temporaire ou autre. Ca te permet de travailler localement, donc gain de performances, et possibilité d'être déconnecté du NAS, la synchronisation se refera quand la connexion sera de nouveau établie. D'où le problème d'utilisation multiple que tu rencontres. Car évidemment chacun travaille sur son fichier, et en fin de compte c'est la version la plus récente qui prime. En faisant du versioning avec Drive, on peut éventuellement récupérer des infos qui auraient été écrasées, mais ça n'évite pas le problème. En direct, celui qui édite ne pourra pas enregistrer car le fichier est en lecture s'il est déjà ouvert par un autre utilisateur. Pour faire ce que tu veux, il faut des outils tels SharePoint de Microsoft, ou Dropbox, etc... Je compatis en tout cas car un bureau dont je m'occupe va passer sur Dropbox à cause de ça. et le NAS ne servira plus qu'à synchroniser les données de Dropbox et faire des sauvegardes.

Bienvenue 6c6m !

Je vous offre les 2 Go en trop ma bonne dame !

Salut et bienvenue. Est-ce que tu peux séparer ta présentation de ta demande ? Merci ! 🙂

Quand tu crées un conteneur dans le réseau bridge par défaut, il prend une IP dans 172.17.0.0/24, et 172.17.0.1 est l'IP passerelle, celle du NAS. Cette IP ne change pas. C'est l'avantage justement par rapport à ton IP locale 192.168 qui pourrait changer. La plage disponible pour tous les réseaux docker, c'est 172.16.0.0/255.240.0.0 (ou encore écrit 172.16.0.0/12) donc de 172.16.0.0 à 172.31.255.255. Outre le réseau bridge par défaut, on peut créer des réseaux bridge personnalisés qui peuvent choisir les réseaux 18, 19, ..., 31. Oui car si tu n'actives pas la case, MariaDB n'est exposé que sur 127.0.0.1, donc localhost, ce qui signifie que seul le NAS peut y accéder. Ton conteneur est considéré comme externe, car dans un sous-réseau déterminé. Ca aurait fonctionné si tu avais été en mode host (le conteneur n'est pas dissocié du NAS du point de vue de l'exposition, seulement au niveau des données).

Bienvenue parmi nous Bruno !

Salut, bienvenue à toi. 🙂

@PiwiLAbruti Mon pfSense en amont s'occupe déjà de tout le filtrage IPv6, donc n'arrive au NAS que le trafic que j'autorise (requêtes ICMP et clients seedbox), donc jamais remarqué de blocage. Cela dit je peux faire le test, je supprime le filtrage de pfSense, je rajoute une règle qui bannit l'espace publique 2000::/3 après mes règles d'autorisation sur mon préfixe personnel, et vérifier sur un temps donné. Je vais essayer de regarder ça cette semaine. Ce sera assez facile à vérifier avec la seedbox.

Ouais ça me semblait logique désolé, c'était à remplacer par le port que tu as affecté. 😛 Pour l'IPv6, je vois plusieurs points qui peuvent te poser problème. Est-ce que ton NAS dispose d'une IPv6 routable ? c'est déjà un préalable pour communiquer avec l'extérieur, une IP routable commencera probablement par "2a" de ton côté. Si c'est le cas, tu peux vérifier que la connectivité est fonctionnelle en faisant un : ping -6 ipv6.google.com Maintenant au niveau du pare-feu, si le but est d'accéder à ton NAS via l'extérieur en IPv6, sans utiliser de NAT, il faut autoriser le protocole ICMP, car autant ton NAS ne sera pas pingable de l'extérieur en IPv4 (ça s'arrête généralement à la box qui les refuse par défaut assez souvent), autant en IPv6 c'est problématique l'ICMP fait partie intégrante de l'établissement d'une connexion entre deux périphériques (en IPv6, ce ne sont pas les routeurs intermédiaires qui font le travail de fragmentation des paquets, mais les périphériques aux extrêmités, la MTU minimale est calculée par ces derniers et assure qu'on peut aller du point A au point Z). Moi j'ai donc une règle en entête qui autorise toutes les requêtes ICMP de toutes les sources (cela comprend IPv6 et IPv4, on ne peut pas les dissocier dans DSM, c'est dommage). Localement, un périphérique peut communiquer via son IP publique avec un autre périphérique sans passer par l'extérieur, car les IPv6 ont une notion de portée que n'ont pas les IPv4. Donc il faut aussi autoriser le préfixe de ton pool d'IPv6 alloué par ton FAI, par exemple moi j'ai autorisé 3 réseaux différents, avec un même préfixe en /56 (fourni par le FAI), mon pare-feu crée ensuite des pools /64 depuis ce /56, et j'autorise ceux qui m'intéressent dans le NAS : Personnellement, je n'ai eu aucun problème à accéder à mon NAS en utilisant le blocage GeoIP en IPv6, visiblement ils importent également les adresses IPv6. Avec tous ces points, tu devrais pouvoir accéder à ton NAS en IPv6 sans problème depuis l'extérieur. Sous réserve de ce que la box permet comme configuration au niveau du pare-feu IPv6 (mais j'ai ouïe dire que la Freebox est relativement configurable par rapport aux box concurrentes).

Ca ce n'est pas normal, voilà ce que j'ai chez moi : On voit bien que l'application est disponible pour les deux protocoles. Pour moi la longueur d'établissement de la connexion vient du fait que ton périphérique essaie de se connecter en IPv6. Mais il n'obtient qu'un timeout, et fait donc un fallback sur de l'IPv4. La question est : comment parvient-il à résoudre si le nom d'hôte utilisé n'amène que vers de l'IPv6 ? Possible qu'il essaie de passer par l'extérieur, si ta zone DNS publique a un enregistrement wildcard. Est-ce que tu as une zone DNS locale ou bien tu te sers de la zone publique et du loopback pour rester dans la boucle locale ?

J'ai subodoré un problème avec l'IPv6 car j'ai un problème quasi similaire avec une application musicale, Mopidy. Mais avec Drive jamais eu de souci. Pour le coup ça ne devrait pas être lié au port de synchro 6690, car quand on essaie de se connecter à Drive via l'application, on n'emploie pas ce port, on utilise le port de l'interface web, 5000 si pas de port personnalisé. J'imagine qu'avec un proxy inversé tu as défini un port personnalisé pour cette application. Tu peux quand même vérifier que Drive est bien exposé pour les adresses IPv6 via : netstat -tunlp | grep PORT_INTERFACE_WEB_DRIVE Est-ce que le problème se produit autant en accès local qu'à distance ? ou seulement à distance ?

Essaie de désactiver l'IPv6 sur ton routeur si c'est activé et réessaie. D'autant plus si tu utilises un proxy inversé. Pour voir si le problème vient de là.

Essaie de changer manuellement les DNS dans Panneau de configuration -> Réseau -> Configurer manuellement les DNS, et tu mets en primaire par exemple 9.9.9.9 et en second 1.0.0.1. Ensuite tu réessaies.