.Shad.

@Lud Je t'ai dit tu peux monter ce que tu veux dans un conteneur : Mais tu ne peux rien monter à la volée. Il faut supprimer le conteneur et le recréer, d'où le fait de favoriser docker-compose qui trivialise le process.

Ca dit que tu ne dois pas, a priori, modifier authelia.subfolder.conf, mais tu peux très bien configurer authelia.subdomain.conf. Je pense comme toi que le problème doit être ailleurs. Dans le MP que tu m'as envoyé je vois une indentation décalée dans les access control, je ne sais pas si ça vient du c/c ? Normalement, les "-" des domaines sont alignés avec policy, networks, etc... Les fichiers yaml sont susceptibles à l'indentation. 😄 J'ai peut-être une idée, essaie de passer adguard.mondomaine.fr dans le bloc cité ci-dessus, et passe la policy à "bypass", pour tester si ça fonctionne déjà.

Non, un conteneur ne prend pas la timezone par défaut de son hôte. Certains conteneurs n'ont ni fichier /etc/timezone, ni variable d'environnement TZ. Ca dépend de ce qu'implémente l'image. @Lud Tu peux toujours monter ce que tu veux dans le conteneur, que ce soit dans /volume1 ou non. Tu peux par exemple taper, pour un conteneur de nom "toto" : docker exec -it toto bash (remplacer par ash ou sh si bash pas disponible). Et taper ensuite : env Tu verras vite s'il existe une variable TZ. Si oui alors tu peux l'ajouter dans les variables d'environnement, même si ce n'est pas repris dans la doc.

Bienvenue parmi nous. 🙂

Tout m'a l'air ok. Tu devrais poster un message ici : https://github.com/janeczku/calibre-web

Python sur DSM n'a rien à voir avec ce qu'utilise Calibre-Web. Calibre-Web utilise Python dans le conteneur, c'est complètement isolé. Pour ma part j'ai re-vérifié aucun problème de mon côté. Est-ce que tu es sûr que les droits des utilisateurs et groupes du NAS n'ont pas changé ? que le combo UID/GID utilisé est encore en mesure de lire/écrire dans les volumes montés dans le conteneur ?

Étonnant que tu sois déçu des performances du DS716+II, c'est quand même une bonne machine. Bienvenue parmi nous ! 🙂

Il faut taper systemctl enable ton_fichier_mount pour que ça se lance au démarrage. On voit dans ton impression d'écran qu'il est désactivé (disabled). Je pense que le temps d'attente est relatif au fait que systemd attend que le réseau soit actif et en ligne avant de faire les montages. fstab ne s'en préoccupe pas. Maia c'est étonnant de perdre une minute au démarrage, perso je n'ai constaté aucune différence de temps de démarrage entre fstab et systemd chez moi.

@Swagme Je pense que tu devrais dans un premier temps effectivement créer une entrée de proxy inversé pour Authelia. Ensuite si tu peux mettre une impression d'écran de : docker ps Et éventuellement m'envoyer en MP le contenu de ton fichier configuration.yml d'Authelia.

Tu peux te contenter de le renommer. Oui

Non pas besoin de redémarrer le NAS, tu peux faire : ip link delete mac0 Sinon attention, je pense que tu l'avais remarqué, mais ovs_eth0 c'est le nom de ton interface principale seulement si tu utilises Virtual Machine Manager.

T'as tout compris. Mais du coup si ton NAS utilise comme DNS l'IP du conteneur Pi-Hole, il ne pourra pas faire de résolution DNS car le serveur sera injoignable. Une solution est de créer l'interface virtuelle, afin d'établir un chemin entre le conteneur et le NAS. Une autre est de faire en sorte que la passerelle passe par un autre port RJ45, si tu en as plusieurs sur ton NAS. La dernière est de configurer manuellement le DNS du NAS pour une IP qu'il peut atteindre (un serveur DNS local autre, le routeur/la box, des DNS publiques, etc...).

On se fera un Teamviewer plutôt, je te dirai quand je peux.

Pas de souci. Ce serait bien que tu désactives le forward sinon on ne pourra pas trouver le problème.

A priori DSM est donc bien exposé sur le serveur VPN (0.0.0.0 signifie toutes les interfaces du NAS). Quoiqu'il en soit, lorsque tu tapes https://ndd.fr:5001 ou https://ns.ndd.fr:5001, en étant connecté au serveur VPN sur le PC ou le Mac autrement qu'en local (je ne parle pas d'une tablette ou d'un GSM dans un premier temps), tu as un avertissement de sécurité ?

Simple, sûrement. Fastidieux, encore plus. Rapide, sûrement pas. 😛

Oui SLAAC c'est le stateless. 😉

On peut vérifier que ton interface émet ou non sur l'IP du serveur VPN, tu te connectes en SSH et tu tapes : netstat -tunlp | grep 5001

Fais F12 sur Chrome et regarde la console, soit ça mouline soit tu as un message d'erreur, ça ne peut pas être autrement.

Aléatoire dans le sens où tu ne la contrôles pas, elle est basée sur la MAC. Et ca c'est valable pour l'IPv6 "vraie" uniquement, pour les temporaires tu n'as aucun contrôle. Une distribution Linux classique (même sur Rpi) fait l'affaire. Mais c'est pas forcément évident à mettre en place. Et la fiabilité d'un Rpi est toute relative. Pour ma part j'utilise aussi SLAAC, la séparation périphériques sécurisés et moins sécurisés je la fais au niveau du réseau même (pas le même VLAN). La réservation DHCP en IPv6 ? Ca veut dire que tu as un serveur DHCPv6 pour lequel tu détermines quel préfixe en /64 ou plus que tu utilises, et que tu as défini une plage DHCP pour tes périphériques ? https://www.networkacademy.io/ccna/ipv6/stateful-dhcpv6 pour des infos sur stateful et stateless en IPv6.

Bienvenue parmi nous.

J'avais testé sur la beta je n'avais pas réussi à aller au bout de la sauvegarde, il faudra que je réessaie.

Si tu n'autorises que des IPv4, normalement ton ordinateur devrait faire un fallback vers IPv4. Il continuera d'utiliser IPv6 pour le reste. Si ça ne fonctionne pas, c'est sûrement ton architecture IPv4 et IPv6 qui fait encore des siennes. Je pense que tu devrais revoir tout ça, car ça t'a déjà amené à des comportements inattendus. @Mic13710 @MilesTEG1 IPv6 ne pose pas de problème outre mesure, simplement si on limite localement l'accès à des périphériques, il ne faut plus faire du stateless mais du stateful, donc avoir un serveur DHCPv6. Plus de génération aléatoire des IP, et donc contrôle total des IPv6 sur le réseau.

Tu obtiens quoi comme erreur ?

@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.