.Shad.

Hello, alors pour ta zone lan, j'aurais fait quelque chose du genre : lan.local NS ns.lan.local lan.local A 172.16.X.X ns.lan.local CNAME lan.local dsm.lan.local CNAME lan.local Même chose pour ta zone vpn, en changeant le sous-réseau privé : lan.local NS ns.lan.local lan.local A 10.0.8.1 ns.lan.local CNAME lan.local dsm.lan.local CNAME lan.local Ces zones ne se différencient que par l'IP finale pointée, les noms de domaine sont identiques, donc passer du LAN au VPN est transparent pour tes montages réseaux. Au niveau de tes vues ça devrait être bon. En revanche, je ne comprends pas pourquoi tu as le mis l'IP du NAS en second redirecteur. Si ta requête n'est pas résolue par ta zone locale, lui redemander ne changera rien. Soit tu actives un ou deux redirecteurs, et dans ce cas-là tu disposes d'un serveur récursif, càd la requête est transmise à un(des) serveur(s) publique(s) de ton choix qui va(vont) retrouver pour toi l'IP de destination. Soit tu ne les actives pas, et dans ce cas-là ton résolveur fonctionne de manière itérative, il va lui-même interroger les serveurs root et redescendre la chaîne des domain level jusqu'à trouver la zone faisant autorité sur l'enregistrement que tu recherches. Dernière chose, joindre un NAS par son nom NetBios ne fonctionne pas en VPN, donc c'est soit par IP soit par nom de domaine.

Bienvenue !

J'ai regardé un peu mais je ne trouve rien de probant, sachant que je ne peux pas non plus faire de tests en direct. De mes recherches, je vois deux "solutions" (je mets entre guillemets car les gens n'expliquent pas pourquoi ça marche d'après eux) : - ajouter include /etc/nginx/mime.types dans le bloc serveur de ton entrée de proxy inversé Pour la deuxième ça me semble déjà plus compréhensible, le principe est d'ajouter un filtre regex sur un deuxième bloc location et de forcer le format pour les fichiers de type .js location ~ .*(\.js) { default_type application/javascript; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app IP_ROUTEUR; set $upstream_port 5000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; }

Il suffit d'enlever l'include qui pose problème dans ton srm.subdomain.conf, et d'ajouter dans ce fichier tout ce qui est habituellement inclus, modulo ce qui pose problème. Ca va être du try and retry pour trouver.

Salut, Ce n'est pas dans Redirections mais dans Zone DNS que tu dois ajouter un enregistrement AAAA vers l'IPv6 de ton NAS. Pour ta box, tu es bien dans la configuration du pare-feu de l'IPv6 et pas dans un onglet de NAT on est d'accord ?

@MilesTEG1 Pour moi c'est lié au fichiers "mime.type" inclus par SWAG dans ses blocs server. Il faut comparer avec ce que tu trouves dans les configs dans /etc/nginx sur ton NAS.

@MilesTEG1 Ca a trait au fait que que le script js exécuté renvoie le mauvais MIME type, "text/plain" au lieu de "text/javascript" de ce que j'en comprends, ici par exemple : https://stackoverflow.com/questions/39228657/disable-chrome-strict-mime-type-checking Après je ne m'y connais clairement assez pour te débugger plus avant personnellement. Il existe visiblement un workaround dans Nginx, mais qui n'est pas conseillé. Est-ce que tu as testé avec d'autres navigateurs ?

Bienvenue parmi nous

Oublié de mettre le lien :

Difficile de dire comme ça ce qui pourrait clocher, je suis tombé sur ce post en recherchant une solution à ton problème, je ne sais pas si ça peut être une piste ? Sinon éventuellement contacter le support, ils sont a priori plus compétents pour ce genre de souci.

Justement, il ne peut pas faire grand chose, c'est tout l'intérêt. Ca permet que si l'image du conteneur était vicitime d'une faille de sécurité, tes données ne seraient aucunement en danger. Tu évites une potentielle backdoor. Sinon, ajout du tutoriel suivant dans la liste des tutoriels en début de post :

Je vois que tu es sous DSM 6, est-ce que tu as bien le paquet exFAT ? (payant, gratuit sous DSM 7)

Salut, Donc aucun accès local ne fonctionne via l'explorateur ? Quel est le message d'erreur renvoyé ? Visiblement la connexion fonctionne entre OpenLDAP et le NAS sinon tu n'arriverais pas à te connecter via le navigateur.

Première question, est-ce que tu as bien fait une sauvegarde avant de procéder à la mise à jour ? Ce serait la meilleure option pour réparer les paquets défectueux.

C'est bien ce que je pensais, ton pare-feu ne filtre rien, ton NAS est exposé au monde entier, tu dois d'urgence aller lire ce sujet : Et surtout mettre en application la partie concernant le réglage du pare-feu.

Et ben si c'est ce que tu ressens je suis désolé, ce n'était pas du tout le but. Docker est difficile à comprendre, mais aussi à expliquer. Quasiment tout est bon je pense dans ta configuration, pour moi c'est juste un problème de permission, si ce que j'ai expliqué dans mon dernier message n'est pas clair je peux essayer de reformuler, n'hésite pas à me dire.

Tu ne peux pas te connecter en SSH avec un utilisateur sans privilège admin au NAS. Mais tu n'as pas besoin, en tapant "id lms" depuis n'importe quel autre utilisateur capable d'accéder au NAS en SSH tu auras l'info dont tu as besoin. Pour la valeur de PUID il faut que tu imposes l'id de l'utilisateur lms. Si tu n'arrives pas à t'en sortir tu peux toujours utiliser l'id de ton utilisateur avec droits d'administrateur (pas "admin", mais l'autre que tu dois avoir créé à l'initialisation du NAS)

C'est plutôt une bonne chose, les accents sont à bannir en informatique. 🙂

Est-ce que sur les autres PC SMBv1 est encore activé ? Et sur le nouveau ? SMBv1 sur Windows : https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server#windows-81-windows-10-and-windows-11-add-or-remove-programs-method

A quoi ressemble le pare-feu de ton NAS ? Est-ce que SMBv1 est bien désactivé ?

Si tu arrives à l'étape du handshake c'est que ton instance est accessible a priori. Est-ce que tu as vérifié si ce que scanne le QR code est ok ? Notamment les clés publiques respectives serveur et client.

C'est ce que j'étais en train d'écrire. Tant mieux si tu as résolu ton problème. Sois vigilant les prochains jours et semaines si tu constates des problèmes de connexion en local.

@Thufir Hello, Tes réglages ont l'air bon à quelques exceptions près, tu n'as pas utilisé les variables d'environnement PUID et PGID, qui te permettent de spécifier un utilisateur créé dans le NAS. Par défaut l'image utilise 1000/1000, qui sont les ID de user et groupe réservées pour le premier utilisateur créé sur une distribution Linux. Sur Synology, ces ID sont réservées à d'autres utilisateurs, et ces utilisateurs ne font pas partie des ACL gérant l'accès aux dossiers partagés. Ce que je te conseille : Tu crées un utilisateur dédié "lms" qui dispose des droits dont tu as besoin, à savoir lecture seule sur le dossier de musiques, et lecture/écriture sur playlists et docker. Tu interdis l'accès aux autres dossiers. Tu l'ajoutes au groupe de base "users" Pour connaître l'ID de ton user "lms", en SSH tu tapes : id lms Tu auras une ID > 1026 normalement, tu la notes. Tu supprimes ton conteneur, tu le recrées à l'identique en ajoutant en variables d'environnement PUID avec la valeur notée juste avant, et PGID avec la valeur 100 (groupe "users"). Tu peux également ajouter le mapping de /etc/localtime du NAS vers /etc/localtime du conteneur, et /etc/TZ du NAS vers /etc/timezone du conteneur. Normalement tu devrais avoir accès aux dossiers mappés.

Bienvenue parmi nous !

@church Mes disques durs à l'époque LDLC étaient toujours bien emballés, presque sur-emballés. Maintenant je commande en Belgique chez Coolblue et Alternate, chaque disque a sa propre boite avec mousse, fermable, et le tout est encore entouré de papier bulle et de mousse de protection. Pour le même prix qu'ailleurs voire moins cher. Donc ce n'est sûrement pas une fatalité.