.Shad.

@Mic13710 En fait généralement le souci en créant le dossier via File Station, c'est que ça utilise un umask bien défini (chez moi c'est 0022, donc pas de droit écriture pour other). Vu que l'utilisateur d'ID 472 sur le NAS ne fait évidemment pas partie du range d'id disponibles gérés par les ACL de DSM pour utilisateur et groupe (1025+ pour les utilisateurs), 472 ne peut pas écrire dans ce dossier. Donc le mieux est généralement de chmod ce dossier pour péter les ACL de DSM et se servir de ses permissions UNIX, en temps normal bypassées. C'est un problème qu'on ne retrouve pas sur les images Linuxserver, car ils utilisent un système astucieux de mappage d'utilisateur entre le conteneur et l'hôte. Si Grafana faisait pareil, en gros tu pourrais via une variable (P)UID et (P)GID préciser à quel utilisateur du NAS correspond l'utilisateur 472 du conteneur. Dans le conteneur tu verrais les volumes montés comme appartenant à 472/root. Et sur le NAS tu verrais l'utilisateur et le groupe précisés dont les id seraient stipulées dans les variables définies ci-avant. Ca règle donc tous les problèmes de droit et permet de ne pas s'affranchir des ACL de DSM. Dans le cas de Grafana on s'en fiche un peu car le contenu des fichiers dans le dossier data n'est pas vraiment confidentiel. Donc même si en pétant les ACL un utilisateur du NAS pouvait y avoir accès, il n'en ferait rien. Je vais sûrement modifier le tutoriel pour utiliser la méthode du chmod plutôt que changer l'utilisateur exécutant le programme.

Oui. Non, aucune raison que ce soit problématique pour le NAS. Non pour les points 1 et 2, pourquoi faire ça ? Ne t'occupe pas de la résolution des conteneurs en bridge ou host, Docker a son propre résolveur DNS qui se base sur les réglages de l'hôte. Donc à moins de vouloir fonctionner différemment, tu n'as rien à faire de ce côté-là. Le Rpi va recevoir l'ordre de s'utiliser comme serveur DNS, donc il va interroger son propre port 53, sur lequel tu as normalement translaté le port 53 d'Adguard (sinon il ne serait pas accessible au reste du réseau vu qu'il est en bridge). Ce qui va le renvoyer vers le NAS. Oui, voir message de @Jeff777. Soit tu configures l'onglet Résolution dans les paramètres généraux de DNS Server. Soit à l'intérieur de la zone locale, pour ne l'appliquer qu'à cette zone. C'est surtout valable si tu crées d'autres zones (publiques, locales avec un autre NDD, VPN, etc...).

A partir du moment où tu utilises SWAG, je te conseillerais de créer un réseau bridge personnalisé comprenant SWAG et les applications qui peuvent être "reverse proxi-ées", exemple : Et dans net-proxy, qui est mon réseau où je mets toutes les applications sensées être accessibles par proxy inversé : SWAG devant communiquer avec redis également, il est aussi dans un deuxième réseau "net-db" qui contient swag et redis (j'utilise MariaDB du NAS). Pour ton problème, je t'avoue qu'à distance comme ça c'est un peu compliqué. Je pense que le problème est ailleurs. Il faudrait qu'on puisse se faire un Teamviewer.

Depuis quel périphérique le ping ? le NAS ?

En fait le point 8 dit de démarrer (start) le service car il n'est pas préexistant. Dans ton cas il faut remplacer start par restart. 😉

Tu dois redémarrer le service. systemctl restart media-moi-ds119j.mount Si tu fais daemon-reload, tu prends juste en compte les modifications dans les fichiers service, mount, etc... mais ça ne les relance pas. C'est peut-être tout simplement ça ton problème. 😉 Aucune idée, mais si non nécessaire alors il faut s'en passer. Laisser SMB2 et large MTU en protocole minimum et SMB3 en maximum. Je ne sais plus. 😄

A priori comme DSM 6, les services sont arrêtés et les volumes de données (/volumeX) sont démontés donc aucun risque d'endommager tes données.

Change le protocole SMB maximum pour SMB3. Et reteste (en laissant par vers=3.0 dans un premier temps). Une bonne raison d'autoriser le protocole SMB1 ? Du matériel non compatible avec des versions plus récentes ?

@rodo37 Possibilité d'ajouter cette section dans la liste des applications C2 ? 🙂

@Swagme Concernant ta configuration access control d'Authelia, pour moi elle est ok, hormis 2 remarques : Je ne vois pas pourquoi tu mets ton IP publique fixe dans le réseau internal L'ordre a son importance, je vois que as trié dans le sens bypass -> two_factor, je te conseillerais de trier plutôt par network. Donc dans ton cas d'abord ce qui prend origine dans le réseau "internal" puis le reste, avec en seconde règle de tri la règle appliquée actuellement. On est d'accord que tu souhaites utiliser un accès 2FA que tu sois en interne ou en externe ? car c'est ce qu'implique ta configuration actuelle. Je n'ai pas trouvé ce fichier. Il se situe où ? Est-ce que Adguard serait en mode host sur ton NAS ? Si tu pouvais mettre une impression d'écran de ton fichier adguard.subdomain.conf ? Et éventuellement du docker-compose d'Adguard (ou simplement dire comment il est configuré, si tu utilises un autre moyen) ? On dirait que plusieurs problèmes se cumulent, les délais à rallonge font penser à des soucis liés au DNS, mais l'erreur 500 à un problème de configuration de SWAG, pas d'Authelia. C'est le fichier /etc/resolv.conf de quoi ? Car là tu as juste une résolution publique, le serveur DNS local n'est pas exploité (sauf en IPv6).

Quels sont les réglages du serveur SMB ? ça se passe ici dans DSM :

@CyberFr Si j'ai bien compris ce que tu as fait, tu n'aurais pas dû avoir à ouvrir le port 5001. Si tu y accèdes par NDD il se peut que tu passes par Internet au lieu de rester dans ton réseau VPN. Fais un nslookup depuis le pc de ton ami sur le domaine. Je pense que tu verras l'IP publique et pas l'IP du serveur VPN. Et normalement, si tu utilises l'IP du serveur VPN au lieu du NDD, ça devrait fonctionner (modulo le message d'avertissement).

Top 👌

Si dans les options du fichier mount tu ajoutes vers=3.0 est-ce que ça marche mieux ? Ne pas oublier daemon-reload entre les deux.

Alors ce n'est pas tout à fait ça, comme tu peux voir dans le tableau dont tu as donné le lien, depuis la 7.3 c'est le groupe qui a changé, l'utilisateur a toujours une ID 472. Ce qui sur le NAS posera problème car un utilisateur 472 n'aura par défaut, pas les droits pour écrire dans le volume que tu auras créé. Il y a une méthode plus simple et qui marchera mieux : tu chmod 777 le dossier data dans /volume1/docker/grafana, tes fichiers appartiendront a priori a 472 / root (472 aura un nom s'il est nommé sur le NAS) et tu n'auras normalement plus de problèmes de permissions.

Pour éviter de diminuer le niveau de sécurité de tout ton NAS (car c'est ce que tu fais avec ce réglage), je t'enjoins à regarder ce tutoriel, il est justement prévu pour le matériel SONOS et autre dont les protocoles de sécurité sont devenus obsolètes :

😉 Ca n'explique en rien ton problème avec Windows.

Si tu utilises l'onglet Réseau, alors tu es probablement connecté en tant qu'invité, ce qui pourrait expliquer les problèmes de droit. Tu n'as rien à démonter dans ce cas-là. Tu cliques dans "Ce PC" dans l'arborescence, puis dans le ruban supérieur -> Connecter un lecteur réseau. Tu choisis une lettre de lecteur libre (par défaut il t'en propose une libre normalement. Puis, si l'IP de ton NAS est 192.168.0.100, tu tapes : \\192.168.0.100\music Ca va te demander avec quel utilisateur tu souhaites accéder au NAS. Et tu auras un lecteur réseau persistant qui contient le contenu du dossier partagé "music". Si tu souhaites démonter ce lecteur, clic droit -> Déconnecter.

@Swagme @oracle7 Le port 3307 c'était juste sur DSM car cohabitaient MariaDB 5 et 10, et le 5 utilisait par défaut le port 3306. Oui, tous les ports sont visibles d'un conteneur à l'autre. Oui.

En même temps si tu ne t'exprimes pas clairement... 🤣

Docker sur DSM n'inclut pas l'IPv6. Je vois pas ce que tu aurais pu mal faire au niveau du réseau. Soit si ça marche tant mieux. 🙂

On peut utiliser les switch qu'on veut. Ils ne seront juste pas pris en charge par l'application. Heureusement qu'ils ne restreignent pas la compatibilité de leur matériel avec d'autres constructeurs.

@milkyway Non car les conteneurs se parlent entre eux. Ce que tu peux faire c'est utiliser le proxy inversé pour Grafana. Je suis dispo vers 21h normalement si tu veux qu'on regarde.

Essaie de refaire un ping avec l'IP locale du NAS sur le réseau physique et pas l'IP passerelle. Si ça fonctionne, remplace 172.18.0.1 par cette IP dans le fichier de configuration. Et relance le conteneur telegraf.

Ca existait déjà, c'est juste qu'il n'y avait pas d'images mais une liste d'applications. Probablement parce que lorsque le VPN est connecté, la requête passe du côté publique. Que donnent en SSH sur le NAS : nslookup www.google.fr nslookup nomdelapp.ndd