.Shad.

Non

Jusque-là il fallait s'amuser à aller dans les réseaux, il était temps !

Je te dis j'ai jamais eu besoin de créer ce dossier. Simplement celui pour les fichiers de configuration stipulé dans la doc.

Oui mais ce que je veux dire c'est que ce chemin concerne le conteneur et pas le NAS. Donc créer ce dossier sur le NAS ne fera rien. 🙂

Un conteneur ne te donnera jamais d'infos dans ses logs ni où que ce soit relatives à un chemin sur le NAS. Uniquement au sein du conteneur. Donc si tu as créé ce dossier sur le NAS c'est logique qu'il soit vide. Un conteneur n'a aucune idée de l'arborescence de son hôte, jamais.

Je n'ai jamais eu besoin de créer autre chose que le dossier config pour les données du conteneur Unifi basé sur l'image de Linuxserver. Où as-tu vu une notification qui te le demande ?

Tu utilises l'uid et gid de l'utilisateur avec lequel tu souhaites exécuter l'application. Je ne sais pas comment tu t'organises pour tes autres conteneurs.

Je ne sais pas ce qu'il en est sur Vaultwarden car j'utilise l'application officielle, mais j'ai l'impression que la version CLI de Bitwarden n'est pas incluse dans la méthode d'installation par le script. Ca me paraît assez raccord avec les instructions d'installation : https://bitwarden.com/help/article/cli/#download-and-install

En même temps ça fait longtemps que j'ai vu tourner sous Reddit la date de fin Juin, début Juillet, donc j'ai plutôt l'impression qu'ils sont dans les temps s'ils sortent la RC d'ici 2-3 semaines. Mais à titre personnel je pense que ça n'arrivera pas avant Août, je n'ai jamais vu une version beta qui n'évolue pas avant la RC ou release. Car les modifications qu'ils font pour corriger les bugs de la beta actuelle peuvent très bien en induire d'autres.

Bienvenue !

Bienvenue !

Bienvenue !!

Heuuuu 🙉

Non, si tu arrives sur un avertissement c'est que tu n'as pas un certificat wildcard, ou que tu fais un renouvellement de type http (avec ouverture de ports) et que blabla.miles.tld n'est pas un domaine pour lequel un certificat a été émis. Pour une 404 il ne faut pas mettre d'enregistrement wildcard dans ta zone DNS publique, et ajouter les domaines que tu utilises seulement. Ainsi blabla.miles.tld n'amènera à rien, donc 404.

Par défaut si tu ne précises rien sous Linux les montages sont faits avec root, et pas ton utilisateur. Et pour peu que les permissions des fichiers montés ressemblent à rwxrwxrwx ça pourrait très bien donner ce que tu expérimentes. Comment montes-tu les partages du NAS ? Par l'interface ou par le terminal ? Via fstab, systemd ou mount tout simplement ?

Oui dans ce cas-là en effet ce n'est pas limitant !

Si tu peux le déplacer sur un autre port c'est tout aussi bien. Si pas, il faudra alors envisager que ton proxy inversé écoute sur un autre port, par exemple 9443. Tu gardes l'avantage du proxy inversé d'exposer la grande majorité de tes applications sur un unique port, mais tu perds l'avantage du port 443 dans le sens où là tu devras taper systématiquement 9443 dans ton URL. Le système de création de liens de partage n'est pas très adapté avec l'utilisation d'un proxy inversé (pourtant fonctionnalité proposée par DSM nativement). Tu dois juste utiliser l'URL avec laquelle tu te connectes, donc https://files.ndd.com/sharing/... Ca sert justement à créer une URL de partage, mais elle sera commune à tous les services, donc si tu y mets files.ndd.com / 80 / 443 (dans les trois champs disponibles) et que tu es connecté sur Filestation, tu vas générer un lien de la forme vue précédemment, ce sera également le cas si tu partages via Moments, DSM, etc... on voit très vite la limitation. Pour moi c'est un gros point noir de DSM, qui ne sera pas corrigé aux dernières nouvelles à la sortie de DSM 7.

@Kuchi69 Je ne connais pas cette box, va falloir fouiller, ce n'est peut-être juste pas possible, je ne sais pas. En revanche tu peux faire un test très simple pour vérifier si c'est bien ça qui bloque. - Tu rediriges non plus 443 vers 443 mais 9443 vers 443. - En 4G, tu tapes dans ton navigateur https://xxx.ndd.com:9443 xxx étant un sous-domaine que tu as déjà défini dans le proxy inversé. Si ça fonctionne c'est que c'est bien ta box qui émet sur le port 443 et qui l'empêche de translater le port. Si pas, il faudra explorer d'autres pistes, mais ça me semble être la plus probable.

Si personne ne t'apporte de solution, des quelques recherches que j'ai faites tu aurais peut-être moyen d'arriver à tes fins en te servant d'un serveur Radius (paquet du NAS), pris en compte par VPN Server d'après la documentation : https://www.synology.com/fr-fr/knowledgebase/DSM/help/RadiusServer/rad_clients C'est juste une idée.

@Kuchi69 Deux choses à vérifier : - Que ta box transfère bien les ports 443 et 80 vers ton NAS - Que l'interface de ta box n'émette pas sur le port 443, c'est pas impossible qu'elle le fasse et du coup elle balance la redirection à la poubelle, sans t'en avertir. Tu as peut-être un réglage dans la box pour modifier le port de son interface.

Il ne faut pas activer le domaine personnalisé pour DSM, juste créer une entrée pointant vers DSM dans le proxy inversé : https://dsm.ndd.com -> http://localhost:5000 Pour l'erreur de certificat, est-ce que dans Panneau de configuration -> Sécurité -> Certificats -> Configurer, tu as bien les différents services associés au bon certificat ?

Est-ce que tu as décoché la case :

Pardon désolé j'ai lu OpenVPN, pourtant ton message était clair. 🤪 Au moins tu sais que tu peux le faire par OpenVPN 👍

https://community.synology.com/enu/forum/17/post/114106 C'est ce que OpenVPN appelle habituellement les "client specific override".

Oui là j'avoue pourquoi avoir mis 120 si c'est 104 que tu veux. 🤪 Si tu souhaites te connecter en VPN n'oublie pas d'ajouter les IP du sous-réseau VPN.