.Shad.

Je ne suis pas sûr que factuellement, DSM puisse avoir SFTP activé et SSH désactivé. Dans l'absolu c'est faisable et ça se configure dans le fichier sshd_config dans /etc, mais je ne sais pas si DSM le fait réellement. Si SSH est exposé et activé sur le port 4826 sur le NAS, est-ce que ça fonctionne ? Pour ton pare-feu, comme je disais plus haut, si tu autorises toutes les connexions françaises sur tous les ports, à quoi servent tes premières règles ?

/run/udev c'est pour pouvoir classer les disques par tag dans Grafana. Pour InfluxDBv2 aucune idée, je ne l'utilise pas. Repars d'une installation clean.

Tu as mis les variables d'environnement qui vont de paire avec le montage de volume ? Mon compose pour Telegraf sur mon VPS si ça peut t'aider, et pas eu besoin de décommenter le "/" dans [inputs.disk] : telegraf: image: telegraf container_name: telegraf networks: - net-monitoring # non-root user needed since 1.20.3 user: 1001:998 environment: - HOST_MOUNT_PREFIX=/hostfs - HOST_PROC=/hostfs/proc - HOST_ETC=/hostfs/etc - HOST_SYS=/hostfs/sys - HOST_VAR=/hostfs/var - HOST_RUN=/hostfs/run volumes: # config - /opt/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # disks input - /etc:/hostfs/etc:ro - /proc:/hostfs/proc:ro - /sys:/hostfs/sys:ro - /var:/hostfs/var:ro - /run:/hostfs/run:ro - /:/hostfs:ro # docker socket mounting - /var/run/docker.sock:/var/run/docker.sock:ro # additionnal MIBs - /var/lib/snmp/mibs:/usr/share/snmp/mibs:ro - /var/lib/snmp/mibs/ietf:/usr/share/snmp/mibs/ietf:ro - /var/lib/snmp/mibs/iana:/usr/share/snmp/mibs/iana:ro # system mounting - /run/udev:/run/udev:ro labels: - "com.centurylinklabs.watchtower.enable=true" depends_on: - influxdb restart: unless-stopped

Quand j'ai regardé ce matin, j'ai vu ton impression d'écran de la console avec 0.0.0.0:8083 en LISTEN, donc si si c'est bon, ça veut dire que la translation s'est bien faite. Pourquoi je ne vois plus ton impression d'écran par contre ? Tu l'as enlevée ? Si 192.168.1.200 est l'IP de ton NAS (tu as écrit 192.168.1.1 dans ton premier post par contre), alors normalement 192.168.1.200:8083 doit t'amener sur la page de connexion de calibre-web. Si il y a un timeout, c'est probablement une mauvaise configuration du conteneur. Quand je demandais des impressions d'écran, c'était des impressions d'écran de la configuration de ton conteneur : variables d'environnement, volumes, ports, etc... Bref les différentes étapes que tu as suivies pour créer ton conteneur. Tu peux également poster les journaux de ton conteneur calibre-web, il y a sûrement des indications sur ce qui ne va pas.

Si tu rediriges 4826 vers 22 du NAS, alors SFTP doit être sur le port 22 (réglage par défaut normalement), c'est normal en l'état que tu n'arrives pas à te connecter. 🙂

Je doute que ce soit faisable. Et je doute aussi que ça change quelque chose en terme de temps d'accès. Dans quel but précis souhaites-tu faire ça ? Je ne m'y connais pas assez en architecture logiciel pour savoir à quel niveau intervient le sock. Intuitivement je dirais que seule la consigne a un lien avec le sock, une fois le transfert établi, le sock n'intervient plus. Et la consigne représente un pouillème du transfert effectif de données.

Bien vu ! je n'avais pas vu qu'il apparaissait aussi juste en-dessous 😛

Tu peux facilement convertir des fichiers avec Handbrake (logiciel gratuit), avec un système de file qui te permet de programmer à l'avance ce que tu veux.

Bienvenue parmi nous, au plaisir de t'aider au détour d'un sujet. 🙂

Si c'est un point qui te tient à coeur, pense à regarder si tu trouves des NUC de deuxième main, ce sont des périphériques très performants et qui consomment très peu. Et là dessus tu n'auras aucun problème pour installer un adaptateur USB3-RJ45 2.5Gb/s.

Bienvenue parmi nous, ton 207+ peut toujours faire l'affaire pour du bête stockage, la valeur à la revente serait de toute façon quasi nulle. 😉

Pour ma part, j'ai encore des soucis pour lire des fichiers video encodés en x265 sur mon navigateur, il me faut télécharger la video pour la visionner avec VLC. Fort heureusement, je n'y accède que très peu via l'explorateur et quasiment toujours via Photos sur mobile. Et là mes périphériques décodent nativement le flux.

Non, DSM 7 ne permet plus l'utilisation de dongle Wifi, et si ma mémoire est bonne je pense que c'était déjà le cas avec les dernières versions de DSM 6. Il y a peut-être moyen de contourner le problème via Docker, mais ton modèle de NAS n'est pas compatible avec le paquet.

Il ne faut pas se contenter d'autoriser le protocole SMBv1 en tant que protocole minimum, il faut aussi activer l'option "Activer l'authentification NTLMv1". Et normalement, quand tu tentes d'accéder à un partage, tu dois préciser l'IP ou le nom Netbios du périphérique ainsi que le nom du dossier partagé voulu : \\192.168.1.xxx\stockage pour un dossier partagé nommé stockage.

@oracle7 C'est pas un peu contradictoire de conseiller quelque chose que tu ne comprends pas ? 😅 Si j'ajoute une entrée du type https://toto.xxx.synology.me:443 vers http://localhost:8080 (bidon, pour l'exemple) dans le proxy inversé du Syno, voilà ce qu'on obtient sur le NAS : root@DS918:/etc/nginx/sites-enabled# cat server.ReverseProxy.conf server { listen 443 ssl; listen [::]:443 ssl; server_name toto.xxx.synology.me ; if ( $host !~ "(^toto.xxx.synology.me$)" ) { return 404; } include /usr/syno/etc/www/certificate/ReverseProxy_12c2e981-4fb5-4ebb-8fb9-c41eccb18f27/cert.conf*; include /usr/syno/etc/security-profile/tls-profile/config/ReverseProxy_12c2e981-4fb5-4ebb-8fb9-c41eccb18f27.conf*; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; location / { proxy_connect_timeout 60; proxy_read_timeout 60; proxy_send_timeout 60; proxy_intercept_errors off; proxy_http_version 1.1; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:8080; } error_page 403 404 500 502 503 504 /dsm_error_page; location /dsm_error_page { internal; root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } } Et toi tu ajoutes les entêtes liés au Websocket, qui est principalement utilisé pour garder une connexion à jour de façon permanente, c'est plus intense en ressource pour l'hôte mais parfois obligatoire comme avec Surveillance Station. Ici c'est facultatif, mais ça ne coûte quasi rien de l'ajouter. Plus d'info sur les websockets : https://www.tutorialspoint.com/how-to-configure-nginx-as-reverse-proxy-for-websocket Comme l'a fait remarquer @MilesTEG1, tu utilises la configuration pour un sous-dossier du site web et pas pour un sous-domaine. Quand tu n'es pas sûr, tu consultes la liste des fichiers préconfigurés ici : https://github.com/linuxserver/reverse-proxy-confs Ce n'est pas à utiliser comme tel car c'est adapté pour une utilisation avec SWAG, qui préfère utiliser plusieurs petits fichiers qu'un seul gros fichier reprenant toute la configuration, mais ça te permet de voir généralement s'il y a des entêtes ou des blocs server particuliers à renseigner. @pbai Quelques impressions d'écran de la configuration de ton conteneur Calibre et de la configuration de ton entrée de proxy inversé pourrait nous aiguiller sur ce qui ne va pas. Est-ce que tu as bien translaté le port 8083 du conteneur sur le même port de ton NAS ? En SSH c'est facile à vériier : netstat -tunlp | grep 8083 Si aucun output c'est que Calibre n'est pas translaté sur ton NAS, et tu ne risques pas de pouvoir y accéder.

Le token c'est l'accès à l'API que tu as dû créer au début du tutoriel. Mais si ça fonctionne d'une façon ou l'autre, ce n'est pas la cause, sinon ça ne marcherait pas quelque soit la méthode utilisée. A quoi ressemble ta tâche DSM ?

Voir point 7-B-2-c-2 de mon tutoriel Docker, il n'y a pas de redirection de port à faire en mode host, vu que le conteneur et l'hôte sont confondus, donc pas besoin de NAT entre le NAS et le conteneur. Autre remarque, pourquoi ne pas nommer le fichier env ?

Moi je le comprends dans l'autre sens, le port 22 de la box est NATé sur le port 4826 du NAS. Du coup @PPORCH3 est-ce que tu as bien modifié le port SFTP dans DSM : Et est-ce que tu as modifié le port SSH ? Il y a des redondances dans ton pare-feu, ce qui pourrait être OK s'il t'arrive de désactiver la règle Tous Tous France Autoriser, sinon un petit nettoyage serait utile. Quel est l'intérêt par contre de caler SFTP sur un autre port que 22 ? Car de toute façon, c'est le port 22 de la box que tu utilises.

@MilesTEG1 L'option de nommage du bridge, c'est le nom de l'interface adhoc créée sur le NAS (172.x.0.1), pas le nom du réseau. Ca évite de se taper un nom d'interface généré aléatoirement. @oracle7 Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères.

@oracle7 Ah oui en effet j'ajouterai la précision, mon nom de réseau était bien plus court, je n'aurais pas imaginé. Et les messages d'erreur sont flous au possible.

@PPORCH3 Quand tu essaies d'accéder à ton NAS depuis l'extérieur, quel port sollicites-tu ? Je ne suis pas d'avoir bien identifié si c'est le port 22 qui est exposé sur ta box ou sur ton NAS.

Ce sont deux sous-réseaux privés liés à ta machine. Ils n'ont aucune raison de se causer entre eux, hormis par l'intermédiaire du NAT sur les hôtes respectifs, aucune raison qu'il y ait donc des problèmes de routage.

@kroumi Première chose à faire, c'est vérifier que ton NAS est accessible depuis l'extérieur, pour ça tu peux utiliser : https://www.yougetsignal.com/tools/open-ports/ Tu dois ouvrir les ports 443 et 80 au monde entier durant le test. Moi, quand je fais le test sur ton nom de domaine, ça me dit que les ports 443 et 80 sont fermés. Or, vu les règles que tu as testées, ça doit être OK pour le NAS, donc recrée les règles de NAT sur ta box, il y a probablement un bug de ce côté-là. Où est hébergée ta zone DNS publique ? PS : Tu peux vérifier l'état de renouvellement et l'historique d'un ou de plusieurs certificats pour un nom de domaine via ce site : https://crt.sh/?q=nasunivers.fr&deduplicate=y

Là en l'état je ne pourrai pas t'aider plus. Je n'ai pas assez de temps libre pour me lancer dans une révision de mon monitoring malheureusement. Si tu arrives à résoudre ton problème n'hésite pas à partager la solution.

C'est énorme 60s de timeout déjà, passer à 10s au lieu de 5s aurait dû suffire si ton réseau n'est pas défectueux. Pour les collections, ce sont tes uniques messages d'erreur ? Ça me semble léger. Tu es bien en log level debug ?