.Shad.

Je pense que je vais bientôt devoir passer aussi au formattage complet du NAS 😞 pour l'instant les mises à jour passent, mais pour combien de temps ? Ca va être rigolo je sens d'éparpiller mes 5 To de données si je veux tout récupérer 😄 (je ne sauvegarde qu'un seul To qui est important, le reste pourrait être perdu au besoin).

@Ange Of Spirit Bienvenue, il faudra tenir compte du fait que ce NAS est complètement dépassé d'un point de vue sécurité, je te recommande de ne pas y stocker des données sensibles, mais pour le sport il peut être intéressant de le faire fonctionner en effet. 🙂

@Annick Vitale Tu es exactement dans le même cas ?

Welcome !

Salut, ça semble logique la date "Modifié le" soit attribuée au jour tu obtiens les photos sur ton disque depuis Google. Je ne vois pas trop ce que tu peux y faire. Le nom des images n'est pas composé de la date d'horodation ?

@mulanee Je ne vois rien qui cloche côté serveur, maintenant quelles sont tes options de montage côté client ? Déjà tu montes les dossiers comment ? via une GUI ? en ligne de commande ? fstab ou systemd ?

@mulanee c'est moi ou tes fichiers appartiennent à un utilisateur d'ID 1 ? C'est anormal ça. Tu as chowné tes fichiers ? On voit que les ACL sont d'application en tout cas. Et normalement les membres du groupe users devraient pouvoir éditer les fichiers, à partir du moment où ces utilisateurs ne font pas aussi partie d'un groupe qui pose des interdictions sur ces fichiers, l'interdiction ayant la préséance sur toute permission accordée par ailleurs. C'est un point à vérifier !

@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 :