.Shad.

@Lelolo J'aurais testé ça : # example to show how to override the smartctl command args (per device), see below for how to override these globally. - device: /dev/sda type: 'sat' commands: metrics_smart_args: '-d sat --xall --json -T permissive' - device: /dev/sdb type: 'sat' commands: metrics_smart_args: '-d sat --xall --json -T permissive' - device: /dev/sdc type: 'sat' commands: metrics_smart_args: '-d sat --xall --json -T permissive' - device: /dev/sdd type: 'sat' commands: metrics_smart_args: '-d sat --xall --json -T permissive' - device: /dev/nvme0 type: 'nvme' - device: /dev/nvme1 type: 'nvme'

@Lelolo Essaie d'ajouter '-d sat' dans ta ligne de commande, je présume que ça a à voir avec le fait que tes disques soient reconnus comme des disques scsi, voir le sujet ici : En ce cas, le collector permet de personnaliser les arguments de la commande smartctl via metrics_scan_args : # example to show how to override the smartctl command args globally #commands: # metrics_smartctl_bin: 'smartctl' # change to provide custom `smartctl` binary path, eg. `/usr/sbin/smartctl` # metrics_scan_args: '--scan --json' # used to detect devices # metrics_info_args: '--info --json' # used to determine device unique ID & register device with Scrutiny # metrics_smart_args: '--xall --json' # used to retrieve smart data for each device. mais tu seras coincé avec tes disques NVME du coup... ? ou alors un créer une deuxième instance de Scrutiny, et séparer les disques SATA des NVME.

C'est là que ça va pas, tu as des disques libellés sda, sdb, sdc et sdd sur ton NAS. Mais dans ton fichier compose tu dis qu'ils doivent s'appeler sata1, sata2, sata3 et sata4 une fois chargés dans le conteneur. Pourquoi pas, sauf que, dans ton fichier collector.yaml, tu spécifies des disques en sdX au lieu de sataX. Logiquement le collector ne trouve rien, lui il ne voit que des sataX. Le plus simple est de déclarer dans ton fichier compose : devices: - /dev/sda - /dev/sdb - /dev/sdc - /dev/sdd Et ça devrait fonctionner.

@Lelolo Quand tu écris : /dev/sdd:/dev/sata4 /dev/sdd correspond au nom du disque sur le NAS, /dev/sata4 correspond au nom qu'il aura dans le conteneur. Cette page pourra t'aider : https://github.com/AnalogJ/scrutiny/blob/master/docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md Personnellement, quand je tape sudo smartctl --scan sur mon NAS, j'ai un message d'erreur : # scan_smart_devices: glob(3) aborted matching pattern /dev/discs/disc* Je pense que ça vient d'une implémentation particulière des disques ou de smartd sur DSM. Et donc, Scrutiny qui exécute aussi cette commande ne parvient pas à faire le scan des disques, il faut en conséquence indiquer à Scrutiny les disques à analyser. Donc j'ai crée un fichier collector.yaml dans le dossier de config ("wgetable" ici : https://raw.githubusercontent.com/AnalogJ/scrutiny/master/example.collector.yaml) Dans mon cas, les disques s'appellent sata1, sata2, sata3 et sata4. J'ai ajouté ce bloc en conséquence : # This block allows you to override/customize the settings for devices detected by # Scrutiny via `smartctl --scan` # See the "--device=TYPE" section of https://linux.die.net/man/8/smartctl # type can be a 'string' or a 'list' devices: - device: /dev/sata1 type: 'sat' - device: /dev/sata2 type: 'sat' - device: /dev/sata3 type: 'sat' - device: /dev/sata4 type: 'sat' et j'ai changé mon fichier compose car je n'ai plus besoin de translater les noms des disques : [...] volumes: # config - /volume1/docker/scrutiny/config:/opt/scrutiny/config - /volume1/docker/scrutiny/influxdb:/opt/scrutiny/influxdb # system mounting - /run/udev:/run/udev:ro devices: # disks - /dev/sata1 - /dev/sata2 - /dev/sata3 - /dev/sata4 [...] Il faut laisser un peu de temps à Scrutiny au démarrage pour réaliser les scans, construire l'instance InfluxDB, et que l'API de Scrutiny soit opérationnelle, mais j'arrive au résultat voulu :

Tu as utilisé un fichier compose ? Je vais essayer de l'installer du week-end sur le NAS voir si ça fonctionne.

C'est uniquement pour le paquet Synology. 😉

Bonjour, Mauvaise surprise hier en mettant à jour MariaDB 10 de la version 10.3.37-1077 vers 10.11.2-1303. J'ai perdu des données au passage, la migration ayant pris un temps dingue (3h environ), alors que mes base de données sont pas spécialement volumineuses. J'ai restauré l'ancienne version via une sauvegarde Hyperbackup de la veille, tout est revenu à la normale. De plus, il semblerait que des problèmes de performances aient été identifiés : MariaDB 10.11x Slow performance over WAN | Synology Community Le support Synology est conscient du problème et travaille à le résoudre. Comme le rappelle Synology avant la mise à jour, pensez à faire une sauvegarde via Hyperbackup de MariaDB avant toute upgrade de paquets importants.

Ok donc c'est vraiment un comportement non désiré, tu as bien fait de leur remonter l'info.

@thepopol777 Est-ce que tu as bien fait la redirection de port pour le port 6690 en TCP sur chacune des box vers les NAS respectifs ? Car la connection refused c'est typiquement une redirection non fait et/ou un pare-feu mal réglé. Assure-toi que dans le pare-feu de chaque NAS le port TCP 6690 est ouvert au monde entier le temps d'un test, et que les redirections sont correctement faites, puis tu vas sur https://www.yougetsignal.com/tools/open-ports/ et tu testes depuis chaque NAS si l'ouverture du port est ok :

@Doonet Salut, tu peux regarder ce tutoriel que j'ai rédigé il y a déjà quelques temps, il doit être toujours valable, si tu rencontres des problèmes n'hésite pas à intervenir dessus. Il y a peut-être quelques adaptations avec DSM 7 mais rien de majeur.

Bienvenue parmi nous ! 🙂

Difficile à dire, peut-être interpeler @maxou56 qui a une meilleure connaissance que moi de Virtual Machine Manager.

@firlin Il existe bien des attaques de type ping flood : Attaque DDoS de type Ping (ICMP) flood | Cloudflare Maintenant, les chances que tu sois pris pour cible... ? Est-ce que ce réglage ne désactive pas également le ping en IPv6 ? qui lui participe à la bonne marche du transfert de données contrairement à l'IPv4.

Je n'ai malheureusement pas moyen de reproduire ton cas en l'état. Quelles données perds-tu à ne pas restaurer les métadonnées (dossier commençant par @) ?

Non, tu dois aller dans Conteneur -> Créer et choisir la bonne image. Non pas besoin. Seule la doc de ton image peut te le dire : apparemment c'est dans /homebridge https://github.com/homebridge/docker-homebridge Je ne comprends pas. "Port local" c'est le port sur lequel tu vas mapper le port interne du conteneur sur ton NAS pour te le rendre accessible si ton conteneur est sur un réseau bridge. Si tu ne le spécifies pas, ton conteneur restera inaccessible. La documentation, dont j'ai donné le lien ci-dessus, recommande toutefois d'utiliser le réseau host, donc que homebridge soit directement exposé sur le NAS, comme si c'était une application native de DSM, ça se règle lors de la création de ton conteneur dans Paramètres avancés -> Réseau. Il faut juste s'assurer en amont que le port de Homebridge n'est pas déjà utilisé par le NAS mais a priori le port 8581 est suffisamment exotique pour ne pas être occupé. Ces étapes sont reprises à cette page https://github.com/homebridge/docker-homebridge/wiki/Homebridge-on-Synology-DSM-6-with-Docker Ca reste tout à fait valable pour DSM 7+

Oui c'est probable. Ca peut aussi être lié au pare-feu du NAS, ou les deux à la fois. Je me rends compte que j'ai lu ton poste en diagonale. En effet, le cas précis que tu évoques ne sera pas possible, il faut prendre l'opération dans l'autre sens si tu veux que ça marche : un fichier ajouté dans TO_NAS2 va être synchronisé sur FROM_NAS1 par Drive Sharesync, la synchronisation étant unidirectionnelle NAS 1 -> NAS 2, si je supprime un fichier dans NAS 1 il disparaît dans NAS 2, en revanche si je le supprime dans NAS 2 il reste présent sur NAS 1. Une fois un fichier synchronisé, tu peux le déplacer du dossier FROM_NAS1 vers un autre dossier. Ca peut être fait manuellement ou via un script qui scanne le répertoire FROM_NAS1 à intervalle régulier. Et tu peux de la même manière par exemple vider le contenu du dossier TO_NAS2 sur NAS 1 sur base d'un intervalle régulier en utilisant le planificateur de tâches de DSM. Concernant ta dernière question, de façon générale il n'est pas recommandé d'exposer publiquement les ports NFS ou SMB. Ce sont des protocoles qui ne sont pas destinés à être utilisés à distance, notamment en terme de performance de transfert à distance, de reprise des téléchargements en cas de coupure, ou tout simplement dans la sphère sécuritaire, ces protocoles étant sensibles au brute-forcing. Si Drive Sharesync devait ne pas répondre à ton besoin, l'utilisation de SSH fera l'affaire au moyen des commandes scp et sftp, mais ça nécessite de mettre les mains dans les cambouis. A ta place j'essaierais d'abord de voir ce qu'il est possible de faire avec Drive Sharesync.

Le plus simple est d'utiliser Synology Drive Sharesync, il synchronise des dossiers partagés entre plusieurs NAS. Et tu peux choisir le sens de la synchro. Synology Drive ShareSync | Synology Drive Server - Synology Centre de connaissances Si tu utilises une connexion distante directe (= pas de QuickConnect), il faudra faire de la redirection du port 6690 en TCP sur la box "distante" vers le NAS2. Même chose côté "1" si NAS1 peut recevoir des données en plus de les transmettre.

1. Tu sauvegardes les données de ton conteneur, en plusieurs fois si besoin. 2. Tu supprimes le conteneur, tu supprimes l'ancienne image, et tu reconstruis le conteneur tel que tu l'as fait la première fois, sur base de la nouvelle image.

@StéphanH Si tu utilises un projet compose dans Container Manager, il suffit d'indiquer la nouvelle image dans la directive "image". Si en revanche tu crées ton conteneur sans passer par un projet, il te faut recréer un conteneur à l'identique en se basant toutefois sur l'image maintenue, càd homebridge/homebridge et pas oznu/homebridge

Bienvenue parmi nous @zebulon60

En jouant sur le pare-feu tu pourrais oui, mais pour peu que ton conteneur SWAG ou Docker déconnerait, tu perdrais l'accès à ton NAS. Je n'y vois pas un grand intérêt à titre personnel.

Bienvenue parmi nous, c'est bien l'usage principal d'un NAS, jusque-là aucun problème 🙂, n'hésite pas à créer un fil dédié pour en discuter plus avant.

Bienvenue tu es au bon endroit !

@CyberFr Je vais essayer de tourner les explications de mes collègues différemment. C'est quoi un code TOTP ? C'est une clé qui, une fois entrée dans un logiciel d'authentification 2 facteurs (quelque soit la plateforme : PC, Android, iOS, Extension de navigateur, etc...) permet de générer un code à 6 chiffres, qui se renouvelle. On peut utiliser cette clé sur autant d'applications et périphériques qu'on veut. Le code généré sera le même et variera au même moment. Il est donc prudent d'avoir a minima deux sources d'authentification 2FA, dans mon cas j'utilise Aegis sur mon smartphone, et je l'ai aussi dans Bitwarden. Avantage de Bitwarden, c'est que même si le serveur est down, j'ai accès au cache du coffre depuis mes différents périphériques. Le code TOTP défini par DSM lorsqu'un utilisateur applique la 2FA à son compte n'est affiché qu'une seule fois. Il est donc important de : L'écrire manuellement sur papier et de le conserver en lieu sûr, sans indiquer ce que c'est, moi je le garde dans mon portefeuille. Configurer cet accès sur deux périphériques a minima. Secure Signin est une version intégrée à DSM, absolument pas obligatoire et plus contraignante selon moi, comme tu as pu le constater. J'ajouterai que les remarques de @Mic13710 sont pertinentes dans le sens où le plus important est d'avoir des credentials robustes conjointement avec les blocages correctement configurés sur le NAS. Le reste est intéressant mais dispensable.

@Patrix Merci du retour, je vais intégrer la remarque.