MilesTEG1

Je pense que c’est tout simplement impossible si tu comptes utiiiser l’aspect synchronisation. En effet le port 6690 n’est pas modifiable… et comme tu ne peux pas router un port sur deux machines différentes dans une box tu est bloqué… enfin ça c’est valable que depuis internet car sur le réseau local ça ne devrait pas poser de soucis. peux tu développer l’utilisation que tu souhaites faire des deux serveurs Drive ?

À tout hasard, est-ce que docket est disponible pour une ton nas ? Si oui tu pourriez déporter le contenu de download station dans une stack VPN sous Docker. Alors tu n’aurais plus de soucis avec ton pms,

Je suis du même avis que @.Shad. Si d'ici janvier-février 2022, il n'y a pas de solution adaptée, je tirerais un trait sur le monitoring du NAS via cette solution... Je ne consulte pas vraiment régulièrement Grafana... donc ce sera pas une grande perte. Cela dit, sentimentalement parlant ça le serait, vu que j'ai fait mes premiers pas avec cette stack 😄

@oracle7 Merci 🙂 Par contre, on a maintenant 2 images bloquées sur une version... Telegraf et InfluxDB... La stack va devenir obsolète... plus de MAJ de sécurité, ni rien... Grafana continue de fonctionner, mais jusqu'à quand...

C'est quoi le n° exact qu'il faut mettre à la place de latest dans l'image du conteneur ? C'est juste 1.20.2 ? image: "telegraf:1.20.2"

Hmmm, perso je toucherais pas les users, et encore moins les permissions sur le docker.socks... Ça me semble trop risqué...

On est un peu HS, mais ça va dépendre de la quantité de données que tu as à restaurer. Moi j'ai mes partages Drive en synchro, je les reconfigure et je laisse tourner la synchro en fond, ça prend le temps que ça prend 🙂 en général en quelques heures c'est fini. Pour iCloud Drive, même topo, faut laisser quelques heures, et avec la fibre, ça va assez vite ^^ Pour OneDrive, idem 😄 Pour les applications (sous macOS), j'utilise un petit script qui utilise HomeBrew pour restaurer toutes les applications installées avec. Tu peux voir ce script ici : https://github.com/MilesTEG1/Backup-and-Restore-macOS-HomeBrew-and-app C'est a adapter à ta situation 😉 Faut avoir fait la phase backup avant 😉 Pour les données non synchronisées, je copie le dernier backup fait sur je NAS juste avant le formatage du mac 😉 via le finder, ça prend un peu de temps, mais ça se fait ^^ Pour windows, avant de formater, j'ai récupérer tous les installeurs en dernière version dans un dossier, et une fois windows réinstallé, je réinstalle les app une par une... (en plus d'avoir fait les mêmes choses pour Drive, OneDrive, iCloud...), avec en plus les données non synchro comme pour le mac. La clé de la rapidité, c'est d'avoir une méthode claire et bien définie pour sauvegarder tout ce qui doit l'être, comme les réglages sur macOS de certaines applications clés. Si c'est pas fait, en effet, c'est une galère et très long à refaire ^^ Par exemple pour configurer mon iTerm2, j'y ai passé pas mal d'heures 🙂 Donc tout perdre et tout refaire... 😅 🤪 Je crois que j'ai jamais fait ainsi 😄 Moi je formate et réinstalle depuis une clé USB sur laquelle j'ai créé l'installeur via une petite commande terminal 😄 Oups, OK, je vais arrêter de te dire de passer à DSM7 parce que cette version est vraiment top et fonctionne très bien, donc on peut y passer sans soucis 🤣 OK, je sors ^^

Le boulot d'une clean install c'est la réinstallation de toutes les applications (surtout celles qui ne sont pas via le MAS, utilise homebrew, ça aide beaucoup ^^), et de récupérer toutes les données. En général j'en ai pour une demi journée 😉 Pour DSM, je pense qu'ils ne permettent pas de revenir en arrière car il y a souvent des modifications de configuration interne très importante, et l'ancienne version ne fonctionnerait plus... c'est une sécurité pour moi, mais c'est vrai que c'est assez contraignant. Maintenant que ça fait plusieurs mois que DSM7 est sorti, il n'y a plus aucunes raisons d'être frileux à son installation. D'autant plus qu'il y a eu depuis des MAJ de DSM7... Mais à toi de voir. Ha ça je savais pas... Bon ça m'importe peu, mon MBA ne peut pas avoir cette MAJ... trop vieux 😮 Et sur l'iMac M1 de ma femme, pas besoin de clean install ^^

Et bien c'est la seule solution pour pouvoir accéder à Plex et aussi à DSM ou à d'autres services... Après, je n'ai pas suivi correctement toute la discussion (/mode fainéant 😄 ) donc je ne sais pas quels sont tes besoins... Mais par exemple, avec le reverse proxy, tu n'ouvres que le port 443 sur ta box (internet 443 -> 443 sur le NAS), et tu peux accéder à : Plex avec : https://plex.ton-ndd.synology.me DSM avec : https://dsm.ton-ndd.synology.me ou toute autre application comme drive : https://drive.ton-ndd.synology.me Le reverse proxy est pour moi la meilleure solution, pour une évolutivité future. Il faut par contre faire un certificat wildcards sur le nom de domaine synology. Mais pour le faire, il faut recréer un certificat car par défaut il n'est pas wildcards. Tu recrées ton certificat en mettant ceci :

Fait la donc cette MAJ 😄 Elle se passe bien, et tu gagneras un système à jour et plus ces pastilles te demandant de faire la MAJ 😄 Blague à part, tu as une raison particulière pour ne pas passer à DSM7 ?

Faut pas de fier à ce que te dis Plex quand tu utilises un Proxy Inversé... j'ai le même message, mais mon PMS est bel et bien accessible depuis internet. (Il faut par contre bien spécifier le port accessible depuis internet ici : J'ai ces réglages là : Le tout avec un certificat LE dans DSM pour mon nom de domaine utilisé pour le serveur plex. edit bis : Faut aussi ajouter une redirection dans le reverse proxy pour accéder à PMS. Moi j'ai ça :

Salut, Je constate une chose similaire... mais que pour les stats Docker. Je ne suis pas allé sur Grafana depuis quelques temps, mais en lisant vos messages je suis allé vérifier... Et j'ai ceci : (ne pas tenir compte du No Data sur le 214play, il est éteint, donc aucune donnée, c'est normal). Mais pour Docker Memory, ou pour les autres infos comme la liste des conteneurs : Je n'ai plus rien... edit : Cela dit j'ai aussi ces lignes dans les logs de Telegraf : 2021-10-31T07:36:20Z E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.21/info": dial unix /var/run/docker.sock: connect: permission denied, 2021-10-31T07:36:20Z E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.21/containers/json?filters=%7B%22status%22%3A%5B%22running%22%5D%7D&limit=0": dial unix /var/run/docker.sock: connect: permission denied Ma version de Docker est : Docker version 20.10.3, build b455053

Il faudra aussi ajouter l'url de connexion dans les régalges du serveur plex, dans URL personnalisée, en plus de celle qui contient l'IP LAN du serveur 😉

Et bien je sais pas ce qu'il s'est passé de mon coté... Peut-être qu'après le reboot, l'interface virtuelle ne s'est pas remise comme il faut... Bref, tout semble refonctionner correctement... J'ai mis l'IP de mon routeur dans la partie DNS personnalisé du NAS, et c'est tout. Dans le cas où l'interface virtuelle ne fonctionnerait plus, le NAS pourra toujours accéder à un serveur DNS fonctionnel ^^ PS : question annexe... Hormis les paquets installés sur le NAS et DSM lui-même, qu'est-ce qui pourrait faire des requêtes DNS en passant par ce réglage ? Tous les conteneurs le peuvent ?

Heu non... Mais après un reboot, elle est censé être présente vu que j'ai un script qui se lance après le reboot... Du coup la prochaine fois je vérifierais. LoL J'ai oublié de faire le copier/coller ici aussi 😉 Ou alors j'ai voyagé dans une faille spatio-temporelle pour atterrir en 2340 😄 Synology a changé de nom au moins 5 fois d'ici là 😜

Ok donc normalement après le reboot que j’ai fait hier soir vers 20h mon interface virtuelle a du être recréée. Ce qui normalement permettait à mon watchtower de ce matin 6h de fonctionner correctement… étrange…

Donc si je comprend bien , si on utilise pas --privileged=true à la création d’un conteneur on n’a pas besoin de refaire l’installation. D’autant plus que ça ne concerne que l’interface dans dsm … pas via la ligne de commande et docker compose car j’ai le souvenir d’avoir déjà mis des cap-add dans certains yml…

Faut que notre spécialiste étudie la nouveauté, et nous prodigue ses bons conseils et son expertise 🙂 @.Shad.

Ha je pensais avoir mis la version 😅 dsm7. Faut que j’ajoute la version dans ma signature 😊

Ok merci ☺️ j’ai donc compris que ça permettait d’améliorer la sécurité des conteneurs. mais du coup faut-il modifier nos docker-compose.yml pour bénéficier de cet ajout de sécurité ? Et du oui comment ?

Salut par ici 🙂 J'ai fait la MAJ du paquet Docker DSM hier soir, et j'ai eu quelques soucis (voir ici : Qu'est-ce que de support de "fine grained control..." ?

Hello par ici 🙂 Dites, depuis que j'ai fait la MAJ du paquet Docker DSM hier soir, j'ai plein de petits soucis... Ça a commencé par Tautulli qui ne pouvait plus se connecter à mon PMS... (je n'ai rien changé niveau réglages...)... Puis j'ai vu cette erreur dans DSM : System failed to get External IP. J'ai rebooté le NAS, et ce dernier s'est éteint (oui je ne me suis pas trompé de ligne pour le clic, j'ai bien choisi redémarrer ^^), et pas moyen de le rallumer au bouton... il a fallu que je débranche la prise d'alimentation du NAS et que je la rebranche pour qu'il se rallume. Bref, voilà pour la mise en situation... Et ce matin, je reçois cet email de Watchtower : Could not do a head request for "lissy93/dashy:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:42909->192.168.2.210:53: i/o timeout Unable to update container "/Dashy": Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Proceeding to next. Could not do a head request for "gitea/gitea:1", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:58762->192.168.2.210:53: i/o timeout Could not do a head request for "grafana/grafana:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:41298->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/tautulli:amd64-latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:34463->192.168.2.210:53: i/o timeout Could not do a head request for "vaultwarden/server:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:38384->192.168.2.210:53: i/o timeout Could not do a head request for "ttionya/vaultwarden-backup:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:39918->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/plex:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:49616->192.168.2.210:53: i/o timeout Found new ghcr.io/linuxserver/plex:latest image (b3c421db2d05) Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:55395->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:49073->192.168.2.210:53: i/o timeout Could not do a head request for "telegraf:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:52051->192.168.2.210:53: i/o timeout Could not do a head request for "influxdb:1.8", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:53334->192.168.2.210:53: i/o timeout Could not do a head request for "ghcr.io/linuxserver/calibre-web:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:48934->192.168.2.210:53: i/o timeout Could not do a head request for "portainer/portainer-ce:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:47582->192.168.2.210:53: i/o timeout Found new portainer/portainer-ce:latest image (a1c22f3d250f) Could not do a head request for "ghcr.io/crazy-max/fail2ban:latest", falling back to regular pull. Reason: Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io on 192.168.2.210:53: read udp 172.17.0.4:40619->192.168.2.210:53: i/o timeout Could not do a head request for "adguard/adguardhome:latest", falling back to regular pull. Reason: Get "https://index.docker.io/v2/": dial tcp: lookup index.docker.io on 192.168.2.210:53: read udp 172.17.0.4:37464->192.168.2.210:53: i/o timeout Stopping /portainer (439b51c93047) with SIGTERM Stopping /plex_PlexMediaServer (476f6d42f77f) with SIGTERM Creating /plex_PlexMediaServer Creating /portainer Removing image 6fd0acb4c97f Removing image bc46de77a3ff Et en copiant/collant ce log... je me rends compte que c'est probablement la résolution DNS qui n'a pas marché... Car 192.168.2.210 c'est mon serveur adguard... Hier j'avais modifié les IP DNS dans DSM pour mettre en 2ème IP celle du routeur, la première étant celle de AdGuard (macvlan). Et pour une raison que j'ignore, ce matin ça a merdé... J'ai tenté là, de mettre que l'IP de mon routeur : pas de soucis cette fois-ci J'ai tenté de repasser sans configurer manuellement le DNS, donc en prenant ce qui est fourni par le serveur DHCP du routeur (donc l'IP de mon AdGuard), et là aussi watchtower n'a pas remonté d'erreurs. (J'ai bien changé le cron pour ce dernier ^^) J'ai remis le DNS personnalisé avec l'IP du routeur. Bref, je ne sais pas ce qu'il s'est passé... je verrais demain. Je vais aller aussi poser ma question sur la dernière MAJ de docker dans le bon sujet ^^ @tout de suite sur l'autre topic. PS : la maj de docker a eu lieu hier soir à 19h30, en même temps que plein d'autres paquets 😉

Haa ok c’est via la page du pms directement 😅 je suppose que tu peux faire confiance mais d’abord tu as installé ton pms comment ? en installant le paquet fourni dans le centre de paquet de dsm ? ou en récupérant sur le site de Plex le spk pour ton nas ?

En ce qui me concerne, vu que suis avec une installation sous Docker, j'ai watchtower qui met à jour tout seul comme un grand l'image fournie par Linuxserver. Donc oui j'ai la version 1.24.4.5081. PS : je ne mets pas à jour avec une version beta 🙂 Tu as récupéré le spk sur quel site ?

Vu les NAS qu'il possède, ce serait probablement une meilleure idée de passer par Docker pour installer Plex 😄