MilesTEG1

Bon bah personne n'a jamais activé cette option là à la création d'un dossier partagé ? Du coup, je me dis que ça doit être utile, donc je migre mes données dans des dossiers ayant cette case cochée... J'ai tenté plusieurs méthodes, pour ceux que ça intéresse 😉 (Faut que le système de fichier soit BTRFS hein ;)) Dossier partagé à migrer : DONNEES Méthode n°1 : Créer un nouveau dossier partagé avec le même nom + _1 (ou autre chose) : DONNEES_1. Copier les données de DONNEES vers DONNEES_1. Renommer le dossier DONNEES en DONNEES_OLD. Renommer DONNEES_1 en DONNEES. Avantages de cette méthode : La copie/déplacement des données est assez rapide. Probablement due au fait qu'elles sont sur le même volume, ou grace au BTRFS... je ne sais pas). Problèmes/Inconvénients posés par cette méthode : Il faut créer un partage, et le paramétrer de 0 (case à cocher :whistle: , mais aussi toutes les permissions...) Le fait de renommer le dossier partagé initial (DONNEES), fait que cette modification est répercutée partout où ce partage est utilisé : Drive, HyperBackup etc... Il faut donc modifier manuellement tous ces services. Pour Synology Drive, il faudra ajouter (à nouveau) manuellement le partage qui était précédemment paramétré. Vous perdrez les versions. Il faut aussi taper le mot de passe du compte lors de la suppression du partage 😮 Méthode n°2 : presque la même Créer un nouveau dossier partagé avec le même nom + _1 (ou autre chose) : DONNEES_1. Déplacer les données de DONNEES vers DONNEES_1. Supprimer le dossier DONNEES. Renommer DONNEES_1 en DONNEES.[/list] Problèmes/inconvénients posés par cette méthode : Il faut créer un partage, et le paramétrer de 0 (case à cocher :whistle: , mais aussi toutes les permissions...) Pour Synology Drive, il faudra ajouter (à nouveau) manuellement le partage qui était précédemment paramétré. Vous perdrez les versions. Il faut aussi taper le mot de passe du compte lors de la suppression du partage 😮 Avantages de cette méthode : La copie/déplacement des données est assez rapide. Probablement due au fait qu'elles sont sur le même volume, ou grace au BTRFS... je ne sais pas). + Les services utilisant ces dossiers partagés semble ne pas être impactés. Cette méthode n°2 est donc à privilégier sur la n°1 😄 mais... Méthode n°3 : plus simple, mais plus longue Changer le partage de volume (en cochant la case "Activation de la somme de controle...") : en ce qui me concerne c'est Volume1 -> Volume2. Changer à nouveau le partage de volume : Volume2 -> Volume1. Inconvénient posé par cette méthode : C'est plus long puisque les données sont déplacées d'un volume (donc d'un disque) à un autre. Avantages de cette méthode : La partie paramétrage est plus rapide 🙂 Les services utilisant ces dossiers partagés ne sont pas être impactés. VERDICT : La méthode n°3 semble la plus indiquée pour ne pas trop s'embêter, mais va prendre plus de temps, et va faire travailler les disques un peu plus. Cependant, si votre partage possède une grande quantité de données, ça peut être très long... donc à ce moment-là, vous préfèrerez probablement passer par la méthode n°2. Cela dit, vous verrez des taux de transferts plus élevé que quand les données passent par le LAN :pt1cable: Sur un dossier de gros fichiers : Voilà voilà , je ne sais pas si ça servira à quelqu'un, mais on sait jamais :jap:

Je pense que les memtest intégrés aux distribution linux ont des soucis avec les MV... Mais celui dédié fonctionne bien. Donc je pense que tu peux recommander une barrette 😉

Bon test sur 8Go : Ça me semble tout bon 😉

Et disons que le memtest dans une machine virtuelle ne semble pas très bien fonctionner... J'en ai lancé un autre depuis le DVD d'ubuntu, et ça fait la même chose : Du coup je ne sais pas quoi te dire... Le machine virtuelle fonctionne... Mais sinon le test fait par Synology Assistant n'a pas rencontré d'erreurs, sur les deux nas que j'ai eu car j'ai du faire remplacer le DS920+. (j'ai remis la même barrette hein ;)) Bon je tente avec un memtest86+ dédié (une iso contenant que ça) : et ça marche mieux ^^ Bon j'ai aussi mis 4Go de RAM pour la MV. Je teste avec 8Go après.

Après avoir galèrer pour installer une version 64bits, sans y arriver... j'ai réinstaller Lubuntu en 64bits, et j'ai pu lancer ceci : Bon après pas sur que ça fonctionne, ça fait plusieurs minutes que c'est la même chose d'affiché...

Hello again, ALors, j'ai lancé un win10 avec 8Go de RAM, puis après l'avoir arrêté, j'ai lancé un Lubuntu avec 9Go de RAM : Les deux ont bien fonctionné. Mais deux choses : d'une part ce sont des versions 32bits que j'avais installé quand j'ai eu le 920+ parce que je n'avais alloué que 2 ou 3Go de ram à l'époque... Et d'autre part je n'ai pas vraiment sollicité la RAM dans ces machines virtuelles, car je ne sais pas vraiment quoi faire pour... Je retente après installation de version 64bits.

Je tente la manip tout à l’heure 😊 Sinon pour le prix là je la vois à quasi 45€ : Bon je l’avais payé 33€ et quelques cet été 🤪

Hello, J'ai mis une barrette de 8Go (Crucial CT8G4SFS8266 8Go (DDR4, 2666 MT/s, PC4-21300, Single Rank x8, SODIMM, 260-Pin) conseillée sur Cachem) dans mon DS920+, elle fonctionne bien (memtest fait avec succès à partir de Synology Assistant) et est reconnue, j'ai donc 12Go de RAM : La commande free me retourne ça : la commande dmidecode renvoie ceci : root@Syno-DS920Plus:~# dmidecode -t memory # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0.1 present. Handle 0x0020, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 8 GB Error Information Handle: No Error Number Of Devices: 2 Handle 0x0021, DMI type 17, 40 bytes Memory Device Array Handle: 0x0020 Error Information Handle: No Error Total Width: 64 bits Data Width: 64 bits Size: 8192 MB Form Factor: SODIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 2400 MT/s Manufacturer: 859B Serial Number: E44F0FB1 Asset Tag: Part Number: CT8G4SFS8266.C8FN Rank: 1 Configured Memory Speed: 2400 MT/s Minimum Voltage: 1.2 V Maximum Voltage: 1.2 V Configured Voltage: 1.2 V Handle 0x0022, DMI type 17, 40 bytes Memory Device Array Handle: 0x0020 Error Information Handle: No Error Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: Row Of Chips Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 1 Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 2400 MT/s Manufacturer: Synology Serial Number: 00000000 Asset Tag: Part Number: Rank: 1 Configured Memory Speed: 2400 MT/s Minimum Voltage: 1.2 V Maximum Voltage: 1.2 V Configured Voltage: 1.2 V Je pense que l'affiche de "Maximum Capacity: 8 GB" n'est là que pour dire qu'officiellement ce NAS/CPU ne supporte que 8Go de RAM. Il faudrait que j'essaie de lancer une MV avec 10Go de ram allouée pour voir si ça plante ou pas pour être fixé si les 12Go reconnue sont bien réel.

Hello 👋 En étant passé sur un DS920+, j'ai gagné le BTRFS que j'utilise comme système de fichier pour mes disques. Lorsque je crée des dossiers partagés, j'ai la possibilité d'activer cette option : Et comme cette option n'est pas modifiable après coup, lorsque j'ai restauré les sauvegardes de mes données lors du changement de NAS (DS214play --> DS920+) je n'ai pas eu a recréer tous les dossiers partagés, mais du coup, ils ont tous cette case non cochée : Est-ce que vous pensez que ça vaut le coup que je me tape la création d'un nouveau dossier partagé DOSSIER-BIS, que je copie les données depuis DOSSIER, puis que je supprime DOSSIER et renomme DOSSIER-BIS en DOSSIER ? Et ce, pour tous les dossiers partagés que j'ai... J'ai tenté l'expérience sur une dossier partagé CloudStation (donc un dossier d'équipe de Synology Drive). J'ai du recréer le lien sur les ordinateurs, car le renommage du dossier à été répercuté dans la console d'administration de Synology Drive... Bon c'est pas dramatique, mais un peu contraignant... Et à priori pour un backup avec HyperBackup, ça n'a pas d'incidence, le dossier renommé ne fait pas doublon avec l'ancien, et ça ne génère pas de versions supplémentaires. Ma question est donc, est-ce que l'activation de cette option apporte un gain en sécurité des données suffisants pour que ça me justifie le temps passer à tout refaire ? (Actuellement je penche quasi pour le faire, car en BTRFS, cette option semble toute indiquée...) Vos avis ? Merci d'avance 👋

Ok, ça peut servir ^^ Merci pour l'info. J'ai mis des websocket à tous mes reverse proxy 😉

@EVOTk merci 🙂 Y a d'autres moment où ça sert de créer ces websocket ?

Tu pourrais, s'il te plait, expliquer ce qu'est le websocket ? Et quand en ajouter un ? (et aussi comment en ajouter un ^^)

Je pensais avoir donné l'info ici aussi 😅 Je n'ai du le faire que HFR 😇 Du coup, je reposte ici deux commandes qui permettent de liste les disques présents en tenant compte de la nouvelle nomenclature : fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]' ls /dev/ | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]' Ha bah en fait si 😛 je l'avais dit ici : (je me disais bien que je l'avais fait 😁)

@bruno78 C'est bien toi qui a DSM7 qui tourne sur ton NAS n'est-ce pas ? Ça fonctionnait bien avec DSM6.2 avant de migrer le NAS en dsm7 ? (pour savoir si le soucis que tu as vient de DSM7 ou pas ^^) Docker est sur mon 920+ avec DSM6.2, et j'ai réussi à monitorer mon 214play qui est en DSM7 pour tester ^^ Mais je ne sais pas si le fait d'avoir telegraf et compagnie sur le DSM7 ne pose pas des soucis chez toi...

Haaa ok 🙂 Je pensais bien qu'on pouvait regrouper diverses instance de docker sur un seul portainer. Je suppose qu'il faut installer un agent sur chaque docker dont on veut placer dans l'instance Portainer qui doit tout afficher ? Bon je n'ai qu'un seul NAS avec un seul Docker donc, je ne m'en servirais pas ^^

C'est quoi cet Agent ? Je viens d'installer la v2.0 de portainer (portainer-ce) avec ce docker-compose : Pas de soucis à la mise à jour et à la recréation du conteneur. Tout semble bien fonctionner.

Hello par ici 😉 Me faut l'avis d'expert en réseau, et plus particulièrement en IP 😉 Je sais que ce qui suit n'est issue de pi-hole, cependant ça arrivait aussi dans pi-hole je crois. (faudrait que je relance le conteneur pour être sur). Mais comme c'est AdGuard Home, qui fonctionne comme pi-hole pour le blocage par DNS des réquètes, je me dis que je pourrais potentiellement avoir une réponse avec vous ici... J'ai installé donc Adguard Home dans docker (qui est un équivalent de pi-hole). Ma question concerne cette adresse qui revient très souvent : [url=https://i.imgur.com/HTnAuwl.png][img]https://i.imgur.com/HTnAuwl.png[/img][/url] Je me suis dis que c'était une IPv6, alors j'ai désactiver l'IPv6 sur mon mac : [url=https://i.imgur.com/L9klZiu.png][img]https://i.imgur.com/L9klZiu.png[/img][/url] mais cette adresse revient toujours. Du coup ça ne doit pas être une ipv6... Je l'ai bloquée, et pour le moment je ne constate pas de soucis avec les ordinateurs qui occasionnent l'apparition de cette adresse. Donc ma question c'est quoi cette adresse ?? Comment identifier ce qui génère son apparition ? car là impossible de définir sur les ordinateurs ce qui pourrait demander l'identification de cette adresse au serveur DNS. C'est une adresse locale comme semble le dire son suffixe [b].local[/b] ? edit : au cas où j'ai masqué une partie de l'adresse... des fois que ce soit une IP à ne pas divulger... edit 2 : voilà le format : XXXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.local 8 chiffres/lettres - 4 chiffres/lettres - 4 chiffres/lettres - 4 chiffres/lettres (bon ici que des chiffres) - 12 chiffres/lettres puis le .local Merci d'avance PS : s'il faut je créerais un sujet dédié ailleurs.

J'essaye à l'occasion 😉

@.Shad. : Pour faire suite à cette histoire de ports exposés, je viens de voir ceci qui pourrait faire ce qu'il faut : Qu'en penses-tu ?

Oui oui 😉 Cf. mon fichier docker-compose mis dans le post suivant : Le fait que le fichier contienne les champs ports ne me pose pas de soucis de fonctionnement, mais comme le dit @.Shad. ça peut poser des soucis de sécurité dans certains cas. Sinon, ok pour la version 2.1 qui fonctionne aussi. Je pense qu'il doit y avoir un formatage différent avec la v2.4... mais où est-ce que ça bloque... Faudrait que je regarde plus en détail ^^

Bon sinon sans les ports, j'ai ces erreurs : Il ne semble pas y avoir de soucis avec les mesures, par exemple les températures des dernières 30s sont bien remontées : Mais dans les autres j'ai pas d'erreurs qui remonte, si ce n'est ceci pour telegraf (la ligne contenant "warn" mise en évidence au milieu) : t=2020-10-12T06:22:48+0000 lvl=info msg="Starting Grafana" logger=server version=7.2.1 commit=72a6c64532 branch=HEAD compiled=2020-10-08T09:00:32+0000, t=2020-10-12T06:22:48+0000 lvl=info msg="Config loaded from" logger=settings file=/usr/share/grafana/conf/defaults.ini, t=2020-10-12T06:22:48+0000 lvl=info msg="Config loaded from" logger=settings file=/etc/grafana/grafana.ini, t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.data=/var/lib/grafana", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.logs=/var/log/grafana", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.plugins=/var/lib/grafana/plugins", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.provisioning=/etc/grafana/provisioning", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from command line" logger=settings arg="default.log.mode=console", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_DATA=/var/lib/grafana", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_LOGS=/var/log/grafana", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PLUGINS=/var/lib/grafana/plugins", t=2020-10-12T06:22:48+0000 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PROVISIONING=/etc/grafana/provisioning", t=2020-10-12T06:22:48+0000 lvl=info msg="Path Home" logger=settings path=/usr/share/grafana, t=2020-10-12T06:22:48+0000 lvl=info msg="Path Data" logger=settings path=/var/lib/grafana, t=2020-10-12T06:22:48+0000 lvl=info msg="Path Logs" logger=settings path=/var/log/grafana, t=2020-10-12T06:22:48+0000 lvl=info msg="Path Plugins" logger=settings path=/var/lib/grafana/plugins, t=2020-10-12T06:22:48+0000 lvl=info msg="Path Provisioning" logger=settings path=/etc/grafana/provisioning, t=2020-10-12T06:22:48+0000 lvl=info msg="App mode production" logger=settings, t=2020-10-12T06:22:48+0000 lvl=info msg="Connecting to DB" logger=sqlstore dbtype=sqlite3, t=2020-10-12T06:22:48+0000 lvl=warn msg="SQLite database file has broader permissions than it should" logger=sqlstore path=/var/lib/grafana/grafana.db mode=-rwxrwxrwx expected=-rw-r-----, t=2020-10-12T06:22:48+0000 lvl=info msg="Starting DB migrations" logger=migrator, t=2020-10-12T06:22:48+0000 lvl=info msg="Starting plugin search" logger=plugins, t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Direct Input", t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Pie Chart", t=2020-10-12T06:22:48+0000 lvl=info msg="Registering plugin" logger=plugins name="Worldmap Panel", t=2020-10-12T06:22:50+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=[::]:3000 protocol=http subUrl= socket=, En réactivant le port pour InfluxDB, je n'ai plus ce message de warning de Grafana. Et en réactivant les ports de Telegraf, je n'ai plus le message d'erreur cité précédemment. Bon après, je ne suis pas sur que ce soit dramatique comme message d'erreur compte tenu que tout semblait fonctionner... Mais là, je vais laisser avec les ports actifs. Ces ports ne sont pas routés en dehors du LAN, et normalement sur mon LAN, je n'ai rien qui pourrait tenté de se connecter sur ces ports là du NAS... Mais je retiens l'avertissement pour les futurs conteneurs : ne pas exposer les ports pour rien 😉

Tes conteneurs sont-ils bien tous dans le même réseau ?

Ok, je vais essayer de refaire les conteneurs sans les ports.

Tu parles des ports de InfluxDB et de Telegraf ? Faut que j'enlève les ports du fichier docker-compose ?

Hello @.Shad. @oracle7 Hier j'ai vu qu'il y avait de nouvelles version pour InfluxDB et Grafana, j'ai donc mis à jour les conteneur en les recréant dans Portainer (en utilisant des stacks créé à cette occasion) après avoir téléchargé la dernière version des images. Et ce matin je me suis dit que ce serait bien de faire un fichier docker-compose tout en un pour les 3 services, afin de faciliter les MAJ. (Ok, y a moyen de faire "plus simple" pour les MAJ, ou du moins plus automatique, mais là je n'utilise que Portainer ^^) Donc voilà mon fichier docker-compose, utilisé avec Portainer pour créer les 3 conteneurs : version: "2" services: influxdb: image: influxdb:latest container_name: monitoring_influxdb hostname: monitoring_influxdb networks: - monitoring_nas environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true volumes: - "/volume1/docker/monitoring/influxdb/data:/var/lib/influxdb" ports: - 8086:8086 restart: unless-stopped telegraf: image: telegraf:latest container_name: monitoring_telegraf hostname: monitoring_telegraf networks: - monitoring_nas volumes: - "/volume1/docker/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/proc:/host/proc:ro" - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro" - "/var/run/docker.sock:/var/run/docker.sock:ro" ports: - 8125:8125/udp - 8092:8092/udp - 8094:8094 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: monitoring_grafana hostname: monitoring_grafana networks: - monitoring_nas volumes: - "/volume1/docker/monitoring/grafana/data:/var/lib/grafana" user: "1111" ports: - 3030:3000 restart: unless-stopped networks: monitoring_nas: external: name: monitoring_nas J'ai copié les 3 dossiers des 3 précédents conteneurs dans un dossier monitoring afin de centraliser le tout aussi au niveau du stockage. Voilà voilà 🙂 Si ça peut servir à quelqu'un 😉 PS : si vous êtes plus doué que moi avec docker-compose, vous pourrez probablement répondre à ceci : J'ai du mettre ceci comme version : erreur : version: "2" Car si je mets ce qui suit, le stack n'est pas créé... j'ai une erreur : version: "2.4" Si vous savez pourquoi ça ne veut pas fonctionner avec une version 2.4, je suis preneur ^^