.Shad.

Oui, comme l'indique ma signature, sur un DS918+ et un DS218+. Rien à déplorer de mon côté, mais je n'utilise quasi aucun paquet tiers, l'ultra majorité tourne sous Docker, et c'est donc indépendant de la version de l'OS. Je m'occupe aussi d'un DS218+ pour le bureau d'un ami, pour l'instant il reste DSM 6, j'attends la prochaine grosse màj pour évaluer le bénéfice de la migration.

Rien n'a changé entre DSM 6 et 7 concernant le proxy inversé, à quoi fais-tu référence ? à l'ancienne méthode du temps de DSM 5 pour avoir un proxy inversé Nginx ? Localement, il faut avoir un routeur/box qui fasse du loopback pour que ça fonctionne en local sans configuration additionnelle. Si ce n'est pas le cas, il faut passer par (mieux) un serveur DNS local qui définit localement les adresses pour chaque ndd ou (moins bien) ajouter des entrées dans le fichier hosts de tes périphériques (valables uniquement pour les périphériques qui le permettent du coup).

@db77 On voit que SMBv1 est autorisé dans ton impression d'écran de DSM, en protocole maximum tu devrais autoriser jusqu'à SMBv3, pas de raison de s'arrêter au 2. Parce que du coup le PC utilise le 2 au maximum. Ceci dit je ne pense pas que ce soit lié à ton problème. La croix grise semble être un problème lié à Windows 10 et pas au NAS. Quand tu dis que tu as autorisé tout le monde, c'est dans le NAS ou sur Windows que tu as fait ces réglages ? Je te conseille de cacher ton adresse mail dans ton impression d'écran du Powershell.

A quel niveau ? utilisateur, groupe ? Est-ce que l'utilisateur que tu utilises n'a aucune interdiction de lecture dans un groupe auquel il appartiendrait ? Est-ce qu'avec un utilisateur administrateur ça fonctionne mieux ? Est-ce que tu as testé de démonter le lecteur et de le remonter ? Vérifie voir quelle version de SMB tu utilises, tu lances Powershell en mode administrateur et tu tapes la commande : Get-SmbConnection Tu auras une liste des montages, et une colonne Dialect qui décrit la version utilisée. Attention que si ton matériel Sonos est assez ancien il ne cause qu'en SMBv1 (NT1), et c'est par défaut désactivé sur le NAS avec DSM 7. Peut-être que ton PC utilise aussi ce protocole, même si W10 par défaut utilise SMBv3.

C'est une release candidate pour les NAS orientés entreprise, mais la version finale pour les NAS pour particuliers (c'est le cas du tien) date de Juillet. Les points auxquels il faut faire attention de mémoire : Désactivation par défaut de SMBv1 (NT1), attention aux périphériques anciens. Je propose une solution alternative : https://www.nas-forum.com/forum/topic/72162-tuto-docker-smbv1/ Avènement de Synology Photos, avec ses bons et mauvais côtés, c'est propre à chacun en fonction de ses attentes (à titre perso la carte et la reconnaissance des objets ne m'intéressent pas tellement par exemple, donc Synology Photos me convient parfaitement). Les dongles ne sont plus pris en charge (ce qui était déjà le cas des Pour le reste, des ajouts intéressants à droite à gauche, une interface moins gourmande en mémoire et plus réactive. Si vraiment besoin de garder Photo Station, tu as toujours l'option vDSM.

@firlin Je pense plutôt que c'est un i majuscule. @db77 Ca c'est ce que tu vois depuis Windows, quand tu te connectes à DSM est-ce que les fichiers sont lisibles, parcourables, etc... ?

Alors j'ai pas de surconsommation CPU à noter. Par contre, Drive n'intègre pas cet outil, il faut utiliser le download tool, qui porte bien son nom, on peut juste télécharger des fichiers du dossier... J'espérais une synchro sur Drive comme avec le NAS.

Bienvenue parmi nous. 🙂

@milkyway @oracle7 C'est une option à passer à la création du réseau, pour donner un nom personnalisé au réseau bridge. Voir tutoriel (ajout d'il y a quelques mois). Je ne vois rien d'anormal dans ton fichier de configuration. Est-ce que tu peux tester un ping vers la passerelle depuis le conteneur ? docker exec -it telegraf ping 172.18.0.1

Bienvenue parmi nous. 🙂

Bienvenue parmi nous. 🙂

Quelle erreur exactement (tu dois pouvoir trouver le code dans la partie développeur de chrome (F12) s'il n'apparaît pas sur la page) ? Pour Telegraf, on voit que quelques données arrivent quand même à être envoyées, mais que certains OID semblent poser problème. De mon côté j'ai vérifié je n'ai pas de message d'alerte. Ce n'est pas un problème de pare-feu sinon tu aurais connection refused plutôt qu'un timeout. Est-ce que tu peux mettre la partie Synology de ton fichier de configuration telegraf.conf ? Peux-tu aussi poster le résultat de : docker exec -it telegraf ls -l /usr/share/snmp/mibs @oracle7 : le montage du socket docker.sock n'est utile que s'il souhaite superviser Docker.

Tu as les profils de contrôle d'accès pour filtrer les IP que tu autorises à utiliser une entrée de proxy inversé en particulier. Sinon les éventuels attaquants n'ont pas besoin de "trouver" les ports, ils font bêtement un "nmap" sur ton IP publique, et ils récupèrent tous les ports ouverts depuis leur IP.

Je regarderai sûrement ça bientôt ! Merci de ton retour en tout cas !

On en trouve sur leboncoin : https://www.leboncoin.fr/recherche?text=Edgerouter

Bienvenue !

@Swagme Pour les réseaux, tu ajoutes dans la définition d'un service ceux qu'il doit rejoindre : service: exemple: name: ... [...] networks: - network1 - network2 - network3 [...] networks: network1: network2: network3: external: true network1 et network2 sont des réseaux internes créés par docker-compose, network3 est un réseau défini de façon externe. Autre remarque, tu n'as pas besoin de translater les ports autres que celui de SWAG. Car seul SWAG a besoin de contacter les autres conteneurs.

Bonne nouvelle ! Mais c'est hallucinant qu'il ait fallu tant de retours de la part des utilisateurs pour qu'ils s'en rendent compte.

Jusque-là tout va bien en tout cas, c'est l'approche recommandée. Il est beaucoup plus simple d'utiliser SWAG et Authelia sur un périphérique à part dont les ports HTTP et HTTPS ne sont pas utilisés comme tu l'as fait. N'utilisant pas LDAP, je vais juste te faire part de ma réflexion. Je ne suis pas certain que le domaine défini dans base_dn doive correspondre au domaine couvert par Authelia. Par exemple, j'utilise le NDD fourni par Synology pour tous les services intrinsèques à DSM : Hyper Backup, Active Backup, FPTS, ... et je pense que LDAP doit en faire partie. Créer une entrée pour LDAP dans SWAG n'a donc à mon avis pas de sens car tu ne passes pas par le proxy inversé pour y accéder. Soit tu utilises le domaine Synology, soit tu peux effectivement utiliser la méthode que tu as citée pour générer un autre certificat wildcard pour mondomaine.fr, ça ne gêne en rien, et te servir d'acme.sh pour le déployer dans DSM. Les deux sont aussi valables l'un que l'autre. Pour revenir au fichier de configuration d'Authelia, dans "url" je mettrais le nom du NAS défini dans mon serveur DNS local. A défaut l'IP locale. Je laisserais la vérification de certificat activée, cela dit tu peux toujours tester de la désactiver voir si la communication se fait bien. Et dans base_dn et bien tu mets les dc correspondant au ndd utilisé pour le NAS. Après je n'ai jamais utilisé LDAP, donc à prendre avec des grosses pincettes. 😉

Pour éviter toute attaque avec l'utilisateur admin, il te suffit de le désactiver. Et d'en créer un autre, avec un bon gros mot de passe des familles, et un nom d'utilisateur plus compliqué et moins évident que "admin". 😉

Pas de quoi. 😉

Et du côté du pare-feu est-ce que tu autorises bien le sous-réseau 172.17.0.0 à communiquer avec le NAS ? Car ça expliquerait tous tes problèmes. Une impression d'écran du pare-feu si tu n'es pas sûr. PS : Ca va il ne s'est pas contenté de te dire de mettre en host, je suis (un peu) rassuré. 🙂

Les interfaces avec une IPv4 dans la plage 172.16.0.0/12 (de 172.16.0.0 à 172.31.255.255) sont les portes d'entrée/sortie des réseaux bridge avec le reste du monde. La docker3b0 correspond à l'interface d'appairage des conteneurs. Ce qui t'intéresse c'est le premier type. 172.17.0.1 représente le NAS dans le réseau bridge par défaut. 172.18.0.1 à 172.31.0.1 représentent le NAS dans les réseaux personnalisés. Ce sont les interfaces de passerelle que tu retrouves dans les logs de ton conteneur icloud. Dans les faits oui, ça revient à ça, mais Docker a son propre système de résolution interne. Normalement tu n'as rien à configurer. Si tu tapes la commande suivante en SSH : docker exec -it icloudpg cat /etc/resolv.conf Tu devrais avoir comme nameserver l'adresse 127.0.0.1 ou 127.0.0.11 D'ailleurs tu peux aussi tester la commande suivante : docker exec -it icloudpg nslookup www.google.fr Et poster le résultat. Pas sûr que la commande soit disponible dans l'image. 2 (3) autres questions : 10.0.1.1 correspond à l'IP locale du routeur ou de la box de ton réseau local ? Si tu recrées le conteneur et que tu ajoutes la ligne suivante dans le script, dis-moi si ça fonctionne : --dns 127.0.0.1 Si pas tu modifies la ligne précédente comme suit, tu recrées le conteneur et tu me dis ce qu'il en est : --dns 80.67.169.12

C'est la solution de facilité, car en fait ce n'est pas une solution. Je suis toujours étonné que des gens du métier se contentent de proposer de faire ça. On perd une partie de l'intérêt d'isolation de Docker en host, on ne le fait généralement que pour de bonnes raisons (problème de NAT, nécessité de broadcast sur le réseau physique). Le réseau bridge utilise la résolution DNS de l'hôte, tu devrais investiguer du côté de ton pare-feu et t'assurer que tu autorises a minima les requêtes DNS (port 53) depuis le sous-réseau 172.17.0.0/255.255.0.0. Dans ton cas il n'y aura aucune différence de fonctionnement entre réseau bridge par défaut et réseau personnalisé (user-defined bridge), les différences sont listées dans mon tutoriel introductif en signature. Car sinon c'est normal que le résolveur DNS renvoie un timeout. En host tu es sur l'IP du NAS, donc le pare-feu n'entre pas en compte (par défaut les requêtes de 127.0.0.1 sont autorisées).

Tu peux aussi te connecter par socket distant, c'est même plus sécurisé (mais moins rapide à mettre en place que l'agent, et on ne peut pas parcourir les volumes distants). Voir mon tutoriel : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ https://www.nas-forum.com/forum/topic/71875-tuto-docker-authelia-serveur-dauthentification/ 🥸 Oublie SSO de Synology, c'est une usine à gaz (tu trouveras juste un tutoriel à ce sujet sur le net, c'est de l'alpha ce paquet rien de mieux). Pas encore actif aux dernières nouvelles, je suis assez dubitatif personnellement. Et ce n'est pas auto-hébergé. Si je perds ma clé 2FA avec Authelia, il me suffit de le désactiver dans SWAG. Je ne perds rien.