.Shad.

Merci de passer par la case Présentation avant de poser tes questions. 🙂 Le port 6281 du NAS distant doit être accessible, et Hyper Backup Vault installé sur ce NAS.

Ca n'a rien à voir. Si le nom d'hôte ne fonctionnait pas, il ne dirait pas que le certificat n'est pas valide. Est-ce que tu as redirigé les ports dont tu as besoin sur ta box vers le routeur et sur le routeur vers le NAS ? Pour le certificat, il faut créer un certificat Let's Encrypt depuis DSM pour ton DDNS.

Ah oui j'ai lu en diagonale 🙂 Prévois quand même une sauvegarde hors site ou dans le cloud. 😉

Pas tout compris à ce que tu as fait, mais tant que ça fonctionne 👌

Ok donc a priori la solution évoquée par @Lelolo est la plus adaptée. En terme de connectivité, il faudra penser à : Translater le port choisi pour Rsync sur la box où se trouve NAS 1 vers celui-ci Régler le pare-feu de NAS 1 pour autoriser uniquement comme IP source l'IP publique de NAS 2, si tu as la chance d'avoir une IP fixe Si IP dynamique, limiter au maximum la surface d'exposition et avoir des mots de passe suffisamment robustes, idéalement un VPN site-à-site serait un gros gain de sécurité

Salut @goudurix Tu ne peux pas facilement utiliser le certificat de ton serveur mail pour ton proxy inversé, et surtout je n'en vois pas l'intérêt, il te suffit de créer un autre certificat pour ton domaine depuis le NAS et associer tes entrées de proxy inversé à celui-ci dans Panneau de configuration -> Sécurité -> Certificat -> Paramètres.

Bienvenue, je confirme il y a tout ce qu'il faut sur ce tutoriel, même s'il est initialement prévu pour DSM 6.

Attention, il faut être prudent quand on parle de synchronisation et de sauvegarde en même temps. Si j'efface mes données sur NAS 2, elles seront également effacées sur NAS 1 si j'ai mis une synchro en place entre les deux. Ca c'est effectivement Sharesync, rsync ou autre alternative. Si j'ai mis en place une sauvegarde de NAS 2 vers NAS 1, mes données sont récupérables même si je les efface de NAS 2, ça c'est Hyper Backup, un script ou alternative. Quel est exactement l'objectif, sauvegarder ou synchroniser ?

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

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 :

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)

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

Je n'ai fait qu'une commande chez eux, c'était du matériel électronique, niveau emballage y avait pas de zèle mais suffisant pour la nature du matériel commandé. C'était il y a deux ans. Alors, mal tombé ? changement de politique ? difficile à dire, tu as pris quelques photos à la réception du colis ? histoire de leur mettre le nez dans la m*rde en cas de problème.

@lsssns Bienvenue parmi nous. Pourrais-tu poser ta question dans un sujet à part ? Histoire de séparer la présentation de la question, plus facile pour les autres utilisateurs qui auront peut-être besoin des mêmes réponses, et qui les trouveront plus aisément si le titre correspond au corps du sujet. 🙂