.Shad.

@Versigny Franck Il manque un espace entre "-" et "/srv/..." Le YAML ça doit être rigoureux 🙂

Hello, on aime bien que les nouveaux membres se présentent avant de poser leur question, ça nous aide à connaître leur niveau en réseau, leur matériel, etc... Ce qui nous permet d'adapter nos réponses à leurs connaissances. Je ne comprends pas le problème, tu parles de GLPI, de Synology Drive, et d'accès local via ...QuickConnect ?

@Vista1967 J'ai trouvé ça, bon courage 😉 RT2600ac and PXE Boot? | Synology Community

@Vista1967 Je comprends le besoin, mais je ne maîtrise pas ce sujet, j'ai la chance d'avoir un pare-feu pour lequel les instructions sont données et ça fonctionne. Quel est le routeur utilisé à ton travail ? un pare-feu d'entreprise ?

Alors, pour info, j'ai foiré une restauration pensant que ça avait planté, sauf que moi il y avait peut-être 2 Go et ça a pris 3h, comme toi au lendemain j'ai trouvé l'opération terminée.

Tu peux mettre des impressions d'écran de ton pare-feu stp ?

@Sehoku Tu peux multiplier les certificats pour un même domaine, ça ne pose aucun problème. 😉

C'est incompatible avec l'agrégation effectivement

1 Gbit/s = 1000 Mbit/s = 1000/8 Mo/s = 125 Mo/s => débit théorique

@Vista1967 @seb773 Là tu as configuré le serveur TFTP, maintenant ton serveur DHCP doit distribuer l'information aux périphériques du réseau : https://docs.linuxserver.io/images/docker-netbootxyz/#router-setup-examples C'est la raison de la présence d'un serveur DHCP dans l'image netbootxyz, néanmoins je trouve ça plus idéal que le serveur DHCP reste sur le routeur. Maintenant il faut que tu vois si tu peux configurer ces options dans ton serveur DHCP.

Comme tu le dis, c'est juste pour lire le log, donc pourquoi monter tout le dossier Vaultwarden dans le conteneur F2B ? Déjà, tu dois trouver où se situe le fichier de log, et ensuite tu dois le monter dans le conteneur comme attendu par la jail (ou alors modifier la jail vaultwarden et vaultwarden-admin) : /volume1/docker/vaultwarden/blablabla/.../nom_du_log_vaultwarden.log:/log/vaultwarden.log:ro Pas besoin de faire tourner ton conteneur en mode privilégié si tu octroies les capacités NET_ADMIN et NET_RAW (je pense que tu as juste copié le compose de l'opened issue ?) L'utilisateur qui a ouvert cette issue précise qu'il a dû ajouter chain = FORWARD dans sa jail (sinon c'est le type DOCKER-USER qui est utilisé). Après pour le contexte, tu utilises un proxy inversé pour accéder à Vaultwarden ?

J'ai épuisé toutes mes idées

@Florfil38 Comment est installé Radarr ? en natif (paquet) ou via Docker ?

Bienvenue !

@Elaraz Ce n'est pas très clair, tu nous parles de Plex mais dans tes impressions d'écran tu montres une entrée de proxy inversé pour une application sur le port 15000 ? Si cette application est sur ton NAS, pourquoi ne pas utiliser localhost plutôt ? As-tu lu le tutoriel dédié => https://www.nas-forum.com/forum/topic/59108-tuto-reverse-proxy/ Est-ce que ton NAS accepte les requêtes sur le port 443 ?

@MattBear Si la pile (stack) est créée dans Portainer, elle ne peut pas l'être dans Container Manager. Portainer permet d'avoir un contrôle limité sur les stacks qui n'ont pas été créées en son sein, mais Container Manager lui ne les affiche pas du tout. Il faut créer tes stacks dans Container Manager si tu veux les voir apparaître.

Tant mieux si c'est résolu mais c'est vraiment étrange.

@Gabin Gabin Est-ce qu'en passant par Container Manager au lieu de Portainer ça fonctionne ?

@bubblehornet Connecte-toi en direct sur ton NAS (tu fixes une IP dans le NAS et ton PC sur la même plage réseau) et essaie de faire des transferts, si les débits sont faibles alors le pb est effectivement au niveau du NAS ou du câble. Si les débits sont satisfaisants le NAS n'est pas à mettre en cause et il faudra chercher ailleurs.

@Gabin Gabin Aucune erreur dans tes logs, juste quelques infos classiques relatives à Apache qui n'ont pas d'importance. En réalité, aucun réglage de DSM ne peut faire que ça fonctionne chez moi et pas chez toi, car les deux conteneurs discutent en direct au sein d'un même réseau sans passer par leur passerelle, le NAS. Par contre, les permissions et propriétés des fichiers et dossiers peuvent être différentes d'une image à l'autre. Il faut donc supprimer tout le dossier Nextcloud, recréer les dossiers config et db en aval, et relancer la stack. L'initialisation a pris près de 5-6 minutes chez moi, je pensais que ça plantait, mais je pouvais constater en même temps que le dossier config se peuplait de fichiers, donc tout semblait normal. Ah, et dernière chose, tant qu'à faire à ta place j'utiliserais aussi l'image Linuxserver de Nextcloud, qui est activement maintenue. Pendant mon test hier j'ai pu voir que le propriétaire des fichiers était un utilisateur système (ID 33), l'image Linuxserver s'assurera que les fichiers appartiendront au PUID/PGID utilisé.

Si tu as un serveur Bind c'est parfait, DNS Server du NAS c'est Bind avec une interface en fait. Il te faut juste créer une zone DNS avec ton ndd.fr, comme ça tu feras du split DNS. Et tu pourras même ajouter des vues par après pour différencier le comportement lorsque tu es par exemple connecté en local ou en VPN (si tu as un serveur VPN). Alors ça dépend, tu as plusieurs possibilités : importer le certificat généré par SWAG dans DSM, fastidieux car manuel créer un certificat pour ton domaine ndd.fr dans DSM, mais sans wildcard, pour avoir le même ndd utilisé, ça va coincer avec le NAT du port 80 déjà utilisé par SWAG normalement pour la redirection http -> https, cela dit si tu utilises HSTS tu peux te passer du port 80 sur SWAG mettre en place un conteneur acme.sh pour générer un certificat wildcard pour ndd.fr avec le déploiement automatisé du certificat dans DSM ==> la meilleure méthode selon moi utiliser le ndd Synology pour les services du NAS qui ne passent par le proxy inversé -> solution du fainéant que j'utilise 😄

@Vista1967 En temps normal j'essaie de lancer les images de mon côté, mais je ne le fais pas avec des conteneurs qui demandent des privilèges élevés et pour des images aussi peu répandues. Si tu cherches un soft qui permet de faire du boot network PXE sous Docker, regarde du côté de netbootxyz par Linuxserver : https://docs.linuxserver.io/images/docker-netbootxyz/ Beaucoup mieux documenté et pour l'avoir installé chez moi ça fonctionne très bien.

J'ai créé la stack chez moi depuis Container Manager et ça marche parfaitement : Est-ce que ton port 8244 est bien ouvert sur le réseau local dans le pare-feu du NAS ?

Donc déjà ça montre qu'il n'y a pas de résolution DNS locale dans ton réseau, à ce titre tu y gagnerais beaucoup en suivant ce tutoriel : Dans ton cas, pour accéder d'un périphérique A à un périphérique B sur ton réseau local, l'IP publique de ta box est sollicitée. Car ne sachant pas vers quoi pointe localement drive.ndd.fr, ton périphérique A s'en remet aux serveurs publiques, qui lui disent que ça pointe chez toi 😄 Le NAT Hair-pinning (appelé aussi parfois loopback), permet à une box de se rendre compte qu'une requête a priori publique provient en fait d'un réseau interne, pour atteindre un périphérique d'un réseau interne, la requête fait donc un "demi-tour" (d'où le terme d'épingle - hairpin) pour revenir au sein de ton réseau. J'ai tendance à penser que la succession de routeurs au sein de ton réseau pourrait perturber ce procédé (pour autant que ta box en soit capable). Lorsque tu es sur les data, ça se passe ainsi : drive.ndd.fr -> résolution publique -> pointe vers l'IP publique : * requête port 443 ? ==> reverse proxy -> interface web * requête port 6690 ? ==> NAS -> transfert de données Drive En local : drive.ndd.fr -> résolution publique (car pas de réso. locale) -> pointe vers l'IP publique -> ? La méthode la plus simple pour moi : Créer un certificat dédié via DSM (par exemple pour le ndd gratuit fourni par Synology) associé aux services Synology non proxiables (Hyperbackup, Drive (données), etc...) ==> nas.toto.synology.me Modifier le fichier hosts de ton Windows (C:\Windows\System32\drivers\etc) et y inclure la ligne : 192.168.10.5 nas.toto.synology.me et c'est le ndd que tu devras mettre dans ton client Synology Drive Windows Quant à la meilleure méthode, elle consiste à mettre en place une zone DNS locale qui permette de faire du split DNS, en gros lorsque tu es en local tu résous localement (avec les IP privées) tes noms de domaine, et en dehors de ton réseau, les mêmes noms de domaine se résolvent publiquement. Ça permet au final : d'avoir les mêmes noms de domaine où qu'on soit de ne pas devoir effectuer la modification sur chaque poste client d'être indépendant des serveurs de nom publiques

@Gabin Gabin Essaie la stack que je t'ai proposée, tjs en tapant db:3306 pour l'hôte. Si ça ne fonctionne toujours pas, tu donnes un nom à chaque conteneur, par exemple : container_name: nextcloud-db # pour MariaDB et container_name: nextcloud # pour Nextcloud et cette fois-ci pour te connecter à la db tu mets nextcloud-db:3306