.Shad.

@Jeff777 J'avais complètement zappé la modif à intégrer 😄 Tant mieux si tout fonctionne toujours 👌

Salut @mulanee, J'ai fait le test via SSH : Je ne vois pas les mêmes permissions suivant l'utilisateur utilisé. Je plaide pour une faille de mon côté sur les permissions UNIX, peut-être que @PiwiLAbruti a une idée ? Quoiqu'il en soit, on voit bien le plus à côté des permissions, ce qui signifie que les ACL sont bien appliquées aux fichiers. Est-ce que toi aussi tu vois le "+" en SSH ? Est-ce que tu n'aurais pas chmoddé tes fichiers par hasard ? (ça pète les ACL) Ca peut aussi venir des options que tu passes (ou ne passe pas) côté client quand tu te connectes via CIFS/SMB.

@HugOil Il faut partir de ce qu'a dit @Mic13710, si tu arrives sur la page de ta box en tapant https://mondomaine.ovh (sous-entendu https://mondomaine.ovh:443) c'est que ta redirection n'est pas active, le plus souvent tout simplement car l'interface de la box émet déjà sur son port 443, et que donc elle ne le translate pas. Est-ce que tu n'aurais pas changé de box ? ou celle-ci aurait-elle reçu une mise à jour importante avec redémarrage à la clé ? Je ne sais pas quel est ton FAI, mais tu dois aller voir dans les réglages de ta box si tu peux choisir le port sur lequel est exposé l'interface, s'il est sur 443 (probable), alors le déplacer devrait résoudre ton problème.

Je veux bien être payé en légumes frais 😄 Bienvenue parmi nous, au plaisir de pouvoir t'aider dans tes projets.

Bienvenue parmi nous ! Bonne lecture 🙂

Comme suggéré précédemment (!), as-tu regardé ce que pourrait faire rclone ? https://rclone.org/install/

Non pas possible. En revanche ton NAS monobaie peut servir de destination de sauvegarde de ton NAS multibaie.

Je pense qu'Hyper Backup ne va pas aimer que tu supprimes toutes les données à chaque fois. Quid de rclone ?

@thepopol777 C'est du port forwarding que tu dois faire, et pas du port triggering. Je t'invite à jeter un oeil au tutoriel suivant, section redirection de ports :

Est-ce que ce message ne serait pas relatif aux droits sur le dossier du Sharepoint plutôt ?

Bienvenue parmi nous !

Welcome !

Comme ça en l'état je ne vois pas trop où ça bloque. Aucun message d'erreur dans les logs de Scrutiny ?

Si ton NAS n'est pas joignable par les moyens usuels via QuickConnect, alors un relais est établi via les serveurs de Synology pour faire transiter les données, donc la lenteur constatée en est sûrement l'origine. Les ports 5000 et 5001 sont pour DSM, avec son bureau. Toi ce qui t'intéresse ici c'est uniquement la synchronisation des données, et celle-ci se fait par le port TCP 6690. C'est un port hardcodé, le NAS qui va initier une synchro tentera de joindre le domaine:6690 ou l'ip:6690, si tu veux pouvoir synchroniser d'un NAS1 à un NAS2 il faut que ce port soit accessible de part et d'autre sur tes box. Je ne réside pas en France, mais de ce que j'ai pu lire il n'a pas l'air aussi difficile que tu as l'air de le penser de demander une IP full stack. Pour le changement de ports, voir mon message ci-dessus.

@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 ! 🙂