.Shad.

Si tu as mis un blocage GeoIP sur le port 443, c'est possible que leur requête soit refusée. Tu as regardé de ce côté-là ? Il y a aussi le fait que la base GeoIP a pu être mise à jour, et bloque la requête alors qu'elle ne le devrait pas.

En dernier recours, essaie peut-être de supprimer tous tes fichiers dans /config, car je ne vois rien qui puisse expliquer ce problème...

Ben a priori c'est t'authentifier via Google par oAuth, mais je ne m'en sers pas donc je l'ai désactivé.

Un dossier précédé d'un @ est un dossier caché, et normalement tu n'as rien à y mettre. Généralement on crée un dossier partagé docker (que Docker crée peut-être même en personne à l'installation du paquet), dans lequel on crée des dossiers par stack (une stack = un ou plusieurs conteneurs). Pour calibre-web, tu crées un dossier calibre-web, dans lequel tu mettras ton fichier docker-compose ainsi que souvent, les volumes que conseille de monter la documentation. Ici, dans le dockerfile, on voit que deux volumes sont exposés, config et books, donc si tu ne les bind pas à un chemin en particulier sur ton NAS, ces dossiers seront créés dans les volumes docker, qui se trouvent dans ce fameux chemin /volume1/@docker/volumes. C'est ce que je fais aussi ici, mais je demande une création à la volée d'un volume "config" (qui s'appellera en vrai nomdelastack_config) dans lequel il mettra les fichiers de config. C'est un choix personnel, la plupart du temps je ne le fais pas car accéder à ces fichiers réclament de passer par SSH, mais dans le cas de Calibre-web, je n'ai rien trouvé d'intéressant à sauvegarder ni à éditer dans le volume /config, donc je le laisse dans les volumes docker, au chaud, où justement on ne s'embête pas avec tous les problèmes de permission et ACL, ça se gère tout seul sans encombre. Si tu installes Portainer, tu pourras facilement voir les volumes docker qui ne sont plus utilisés, car dépendant d'une image que tu n'utilises plus, ou d'une précédent installation, et en deux clics tu peux les nettoyer.

@pateretwo Salut et merci pour la remarque, en fait j'avais déjà corrigé quelques versions avant et je ne sais pas pourquoi j'avais zappé de mettre à jour le tutoriel, le mal est réparé. 🙂 Pour info, l'équipe de développement d'Authelia reconnaît que ce changement aurait dû induire une upgrade majeure (v5) vu que c'est un "breaking change". Ce n'est pas un mal d'utiliser watchtower, même en prod, car le retour en arrière est simplissime, tu modifie simplement de latest à une version spécifique et c'est reparti (sauf si des paquets de gens dépendent de toi évidemment...). Pour info je vais bientôt ajouter la méthode de connexion via DuoAPI, simplement je l'ai fait y a longtemps sans prendre note 😄 je vais bientôt le mettre pour ma femme ce sera l'occasion de décortiquer la méthode.

Aucune raison que passer par l'interface de DSM pose problème en effet, cela dit je n'avais pas la motivation de décrire étape après étape. 😄 Tu peux utiliser un tel fichier par exemple, moi c'est sur une debian qui pointe via SMB sur le NAS qui héberge la base de données Calibre, à adapter donc. Fais un backup du dossier correspondant à /config avant, et supprime le pour partir d'une base propre. version: "2.1" services: calibre-web: image: lscr.io/linuxserver/calibre-web container_name: calibre-web network_mode: bridge environment: - PUID=1000 - PGID=1000 - DOCKER_MODS=linuxserver/calibre-web:calibre - OAUTHLIB_RELAX_TOKEN_SCOPE=0 - TZ=Europe/Brussels volumes: # config - config:/config # library - /mnt/nas/calibre:/books labels: # watchtower label only monitoring - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped volumes: config:

Bienvenue parmi nous !

Je t'avoue que là comme ça je ne sais pas, les noms des périphériques qui apparaissent correspondent-ils bien au nom NetBIOS ? Si tu changes celui du NAS est-ce qu'il change bien sur l'application ?

Si tu es prêt à utiliser docker-compose on peut te faire un fichier personnalisé à ton installation.

Ce que tu cherches s'appelle un reverse proxy. Il y a un tutoriel à ce sujet.

Et ça ne marche pas mieux ?

Ce que tu peux faire alors c'est enlever la partie avec le port 445 et laisser 139, donc faire en sorte d'avoir : <?xml version="1.0" standalone='no'?> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_smb._tcp</type> <port>139</port> </service> </service-group> Pareil, docker-compose down, puis up -d. Tu peux le vérifier via les ports en écoute : docker exec -it samba-nt1 netstat -tunlp Si tu vois une ligne (ou deux si IPv6 activée) avec le port 139 pour le service smbd c'est que c'est pris en compte. EDIT : Si on laisse les deux, on prend le risque d'avoir un conflit et que l'un des deux ne soit pas pris en compte. Le port 139 est relatif à l'ancien service de résolution NetBIOS, donc ce sera peut-être plus compatible avec ton matériel.

Tu fais juste docker-compose down, tu édites le fichier, puis up -d. En tapant ceci sur le NAS en SSH : docker exec -it <container_name> smbpasswd <username> Mais pourquoi ne pas simplement changer la variable quand tu recrées le conteneur ? _________________________________________________ Sinon pour ton problème avec les caméras, peux-tu tester ça : tu crées un dossier avahi dans /volume1/docker/samba-nt1/ tu crées un fichier samba.service dans ce dossier et tu le peuples ainsi : <?xml version="1.0" standalone='no'?> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_smb._tcp</type> <port>139</port> </service> </service-group> Puis dans le fichier compose, dans la partie volumes, tu ajoutes : - /volume1/docker/samba-nt1/avahi:/external/avahi Tu relances ensuite le conteneur : docker restart samba-nt1

Par défaut, suite à une de mes demandes, le créateur de l'image avait ajouté WSDD2 pour permettre, sur W10, la découverte des périphériques réseaux via l'onglet Réseau. Quel est le modèle de tes périphériques ? Ca permettra peut-être de voir plus précisément quels protocoles ils utilisent.

Hmm il faut que je regarde plus en détail. Les seuls tests que j'ai pu faire sont à partir d'un client samba sous Docker, ça restait très théorique. Je vais regarder ça plus en détail demain je suis en congé. Je pense que ça peut être lié à WSDD2, tu peux essayer d'ajouter dans ton fichier compose : cap_add: - NET_ADMIN Je doute que ça change quelque chose, mais l'image a pas mal évolué entre la rédaction de ce tutoriel et aujourd'hui. Je t'avoue qu'en plus c'est pas évident de s'y replonger, c'est sûrement le tutoriel qui m'a demandé le plus de travail, et vu que tu es le premier à le mettre en place, depuis le temps j'ai zappé pas mal de choses que j'avais réalisées. 😛 Je regarde demain si la suggestion ci-avant ne résout pas ton problème. 😉

Quand tu es dans un terminal, le fait de mettre des "\" permet justement de faire des retours à la ligne sans couper la commande. Ou alors tu écris tout à la suite. Pense à mettre sudo devant si pas connecté en root. Il faut utiliser l'interface qui possède l'IP de ton NAS, a priori bond0.

Oui toto c'est l'exemple de nom de réseau que tu peux donner, ici ce serait mac0. C'est juste une ligne de commande à entrer en SSH. Ça se met pas dans un composé, en théorie ça pourrait mais c'est se prendre la tête pour rien. Outre les plages d'IP, vérifier le nom de ton interface (ovs_eth0 dans mon cas).

C'est ma faute, j'ai indenté networks sous services, alors qu'ils doivent être alignés. Je corrige de suite, merci. 🙂

Et est-ce que le groupe users n'a pas d'interdiction sur les dossiers en question ? j'imagine que non, mais une interdiction prend le pas sur tout le reste, donc ça vaut le coup de vérifier. Difficile à dire qui a créé quoi, voilà pourquoi je préfère passer par Docker, car il ne touche pas au système.

@lightman77 Soit je n'ai pas compris ton problème, soit tu te compliques la vie pour rien. Si ton réseau local est en 192.168.0.x et le réseau distant aussi, tu t'exposes nécessairement à des problèmes de routage. Donc par exemple 192.168.100.0/24 (de 192.168.100.1 à 192.168.100.254) sur ton réseau local et 192.168.110.0/24 (de 192.168.110.1 à 192.168.110.254) pour ton réseau client. Les plages ne se chevauchent pas, et OpenVPN s'occupera de créer les routes nécessaires à ton client pour atteindre ton NAS et les périphériques de ton réseau local. Assure-toi d'avoir coché la case autorisant l'accès au serveur LAN, pour que ton NAS ne soit pas seul accessible, mais aussi ton imprimante et tout autre périphérique dont tu aurais besoin.

Bienvenue parmi nous !

Tu veux dire que ton réseau local et celui depuis lequel tu te connectes sont tous les deux sur la même plage ? Si c'est ça il suffit simplement de changer ton masque, de manière générale on évite de rester sur du 192.168.0.x et 192.168.1.x, c'est utilisé partout. Par exemple 192.168.100.x ou 10.x.x.x, tu seras beaucoup moins embêté.

Bienvenue parmi nous ! Je suis niçois 🙂

Pour la version packagée, vérifie si tu as un utilisateur Emby dans DSM, et si ce dernier a bien les droits nécessaires que ce soit via le panneau des utilisateurs ou des groupes auxquels il appartient sur les dossiers que tu souhaites parcourir. Je ne pense pas que l'IPv6 ait un rapport avec ton problème de dossier vide.

Probablement car il y a du transcodage quelque part, et vu que tu n'as pas monté le driver graphique de ton CPU dans le conteneur, il ne peut pas l'utiliser, du coup c'est le CPU qui travaille à crever. Mais tu ne peux pas faire ça depuis l'interface de Docker, il faut passer en SSH, car tu dois monter des fichiers hors du volume des données. On peut regarder ensemble mais seulement si le SSH ne te rebute pas, tutoriel ici :