.Shad.

Le compte root n'a pas de mot de passe sur les NAS Synology. Le seul moyen de se connecter en direct avec root c'est avec une clé SSH. Si tu te log via ton script en root sur ton NAS, à aucun moment tu n'es sensé entrer un mot de passe. Sinon tu peux tenter ce que propose ce lien, mais j'essaierais de trouver une autre solution à ta place :

Ce topic parle de la possibilité de faire ce que tu veux, mais je ne m'y aventurerais pas, on touche aux permissions et aux appartenances du fichier cœur de Docker. Est-ce que tu utilises une clé SSH pour te connecter en root depuis ton iPhone ? Il y a moyen de ne pas mettre de mot de passe quand on crée une clé.

Je pense que les WD Red 4 To sont les disques WD les plus utilisés honnêtement 🙂 Après fais comme tu le sens, j'en ai installé deux dans le NAS d'un ami (DS218+).

L'architecture n'est pas liée au software mais au hardware. Par défaut quand tu télécharges une image, pour une écrasante majorité, tu n'as pas à préciser l'architecture, Docker détectera automatiquement ton type de processeur, donc l'architecture, et donc l'image à utiliser en conséquence. Les NAS Syno compatibles Docker utilisent les images pour chipset x86_64. J'en parle dans le tutoriel, je ne m'y attarde pas car il y aurait trop à dire. Le paquet Docker de DSM vient avec docker-compose. Et oui les conteneurs sont visibles dans l'interface de DSM. Pour ma part je n'utilise que ça et Portainer pour la visualisation. Si tu montes des dossiers distants dans ton NAS, c'est dans /volume1 que ça se passe (si tu passes par File Station pour ça en tout cas). Tu n'as qu'à utiliser les dossiers montés dans tes volumes.

T'inquiète pas ils sont compatibles sans problème.

La seule différence entre les WD Red et les Ironwolf c'est la vitesse de rotation, plus importante chez Seagate, donc un peu plus bruyant, pour peu que ce soit un critère dans ton installation.

Bienvenue !

Si tu es perdu je te conseille de lire le tutoriel sur la sécurisation d'un NAS c'est le minimum. On y parle notamment de ce qui concerne l'accès externe. D'ailleurs tu parles te connecter via le finder à distance, c'est possible en VPN entre autre. Mais pas sans rien configurer.

Tu as bien testé cette suggestion de @maxou56 ? Les DNS sont fréquemment coupables pour ce genre de problème.

Salut, Pour moi ça vient du fait que l'IP n'est pas transparente pour le backend, car il voit l'IP du proxy inversé et pas l'IP source. Donc tu peux essayer d'ajouter dans les en-têtes personnalisés : Upgrade $http_upgrade Connection $connection_upgrade X-Real-IP $remote_addr X-Forwarded-For $proxy_add_x_forwarded_for X-Forwarded-Proto $proxy_x_forwarded_proto

Le proxy ne s'applique qu'à l'interface de Drive, pas au transfert de données. Interface => 10002 par défaut Drive => 6690, pas "reverse-proxiable"

J'ai acheté 2 WD Blue 4 To CMR pour le NAS maison, je vais voir ce qu'ils donnent, vu que les Red ça a l'air d'être en partie du marketing (et beaucoup moins chers surtout).

Ça sortirait clairement du contexte de ce site, il y a d'autres forums plus adaptés à cela 😉 Je conseille à tous la lecture de Reddit, ça regorge d'information sur les Syno dans le sub-reddit Synology. Pour info j'ai franchi le pas, mais je pense que ça va être une sandbox quelques temps, je ne suis pas encore prêt à renoncer à tout un tas de facilités efficacement proposées par Synology. 🙂

Typiquement l'erreur liée au fait que tu n'aies pas ajouté sudo au début de ta commande. Par défaut tous les comptes utilisateurs, même admin, n'appartiennent pas au groupe docker. Donc soit ajouter sudo en début de commande, soit te connecter en root via SSH et taper la même commande.

A priori difficile d'y voir un rapport, mais bon attendons 😛

Bienvenue parmi nous 🙂

Assez intuitivement c'est : docker restart <nom_du_conteneur> pour redémarrer un conteneur. Sinon : docker --help donne ce genre d'information.

Heu non attention là ça couvre aussi des IP publiques. C'est respectivement 172.16.0.0/255.240.0.0 et 192.168.0.0/255.255.0.0 au minimum pour couvrir les réseaux privés.

Bienvenue parmi nous 🙂

C'est tout à fait possible à mon avis (théoriquement, je n'ai jamais testé) : - Soit tu montes le dossier du NAS contenant les binaires python dans ton conteneur telegraf. - Soit à mon avis la solution la plus propre pour ne pas toucher au NAS : tu utilises la fonctionnalité volume de docker. volume permet de créer un volume utilisable par n'importe quel autre conteneur. Tu crées donc un conteneur python (l'image officielle existe) et tu crées un volume avec les binaires python, tu pourras l'utiliser dans n'importe quel autre conteneur. Les volumes comme les networks peuvent être définis globalement, pas seulement dans les conteneurs. Voir https://docs.docker.com/compose/compose-file/compose-file-v2/#volumes pour plus d'info sur les volumes.

C'est vraiment pauvre en info, il a l'air de parler d'un conflit d'IP, ce qui pourrait expliquer une inaccessibilité, mais pas le comportement des LED. Et puis je doute qu'il puisse y avoir dans ton réseau local un conflit d'IP. Peut-être l'occasion d'ouvrir un ticket avec le support.

Pour le script qu'on a en test avec @Jeff777 (renouvellement automatisé d'un certificat wildcard pour DNS auto-hébergé) on attend le renouvellement naturel (sans passer par --force) pour vérifier si tout est OK, fin août normalement.

Comme ça non, le mieux étant que tu consultes /var/log/messages après le redémarrage, voir var/log/dmesg et syslog.

Je parle du port par lequel transitent les données, pour les interfaces web elles sont tout à fait accessibles par proxy inversé (pour ABB et Drive).

Aux dernières nouvelles on ne peut pas, comme Active Backup for Business ou Hyperbackup Vault. Oh alors avec des en-têtes spéciaux dont je n'ai pas connaissance.