JacquesF

Bonjour, NAS, sauvegardes, serveur vidéo (via Emby et Kodi sur un Pi4), serveur SVN essentiellement (le plus étant la vidéo et les fonctions NAS). Le RAID est du raid logiciel sur une couche LVM pour le SHR, raid soft classique autrement. Accessible sans problème avec toute distribution linux. Jacques

Bonjour, Le type de disque (SMR/CMR) n'est pas en cause. La configuration du SataPortMap pourrait éventuellement l'être, mais si une fois le DSM démarré la carte PCIe n'est pas vue, ça n'y changera rien. Recherche sur le forum (y compris en anglais) le type de la carte pour voir s'il est pris en compte avec un driver spécifique (fichier extra.lzma à mettre sur la clef). Sinon, regarde les cartes déclarées compatibles avec Synology dans le forum et remplace ta carte actuelle, ou regarde s'il n'y a pas un port dédié pour un CD/DVD sur la carte mère et tente de mettre le disque dessus. Jacques

Bonjour Bruno, Le DSM est installé sur tous les disques, la carte SD sert juste à démarrer le système en lui présentant un pseudo environnement Synology. Donc, refaire la carte devrait suffire, l'OS n'ayant pas changé. Le démarrage "normal" doit fonctionner. Ensuite, mettre la copie de la carte ailleurs serait une bonne chose. Sinon une clef USB peut suffire aussi, mais en ce cas les PID/VID seront différents. Jacques

Bonjour, Si l'arrêt a été propre, il n'y a pas de raison que les données soient corrompues. La carte SD est probablement en cause, au niveau du loader. La refaire avec le même loader (jun 3617 1.03b) devrait marcher, en remettant les PID/VID et les adresses des interfaces réseaux, en principe un truc du genre : set vid=0x0424 set pid=0x4030 set mac1=D0BF9C------ set mac2=D0BF9C------ pour une carte SD et les interfaces du la carte mère. Jacques

Bonjour, Le DSM s'installe sur une partition (de mémoire la première) en RAID miroir sur tous les disques. Le swap est sur la partition suivante selon le même principe, la dernière partition contient les données (raid, ou volume local selon la configuration choisie pour chaque volume). Installer un DSM en test sur un disque unique permet de tester la compatibilité du loader, du DSM avec le matériel. En plaçant des données sur ce disque, on peut vérifier le bon fonctionnement des applications. Ensuite, pour la migration des disques de prod, on a au moins la certitude que le DSM fonctionne (ou non) et si on a pris la précaution d'installer la version actuelle du DSM sur le disque de test avant la migration, celle-ci devrait se passer sans problème sur le matériel (et les données) de prod. Tant que l'installeur ne propose pas de formater les partitions de données, il n'y a pas de risque pour celles-ci. Jacques

Voici le lien vers toutes les versions de DSM : https://archive.synology.com/download/Os/DSM Jacques

En principe, les cartes Intel sont correctement détectées. J'ai une Dual-Port D33682b qui est reconnue sans problème. Mais une carte avec un seul port est plus accessible question tarif. La question est abordée régulièrement sur le forum, faire une recherche serait plus efficace. Jacques

Bonjour, Jamais utilisé HyperBackup, mais le problème est , à mon avis, lié à l'emplacement du package (passé de Volume1 à Volume2). En utilisant la commande grep pour rechercher le volume concerné dans les fichiers de configuration (du NAS et de l'application, emplacements que j'ignore, désolé), il est peut-être possible de les modifier pour corriger le problème. Sinon, avant de recréer une VM comme suggéré, ce qui devrait fonctionner en principe si les paquets sont installés dans le volume présent, je tenterai les actions suivantes : - Créer un lien /volume1 vers /volume2 et vois ce que ça donne. - Si ça ne marche pas, créer un répertoire /volume1 et monter /volume2 dedans (option --bind de mount) - En dernier recours, désinstaller HB et purger toute la configuration et le réinstaller dans le bon volume et recommencer le test. Jacques

Ah ces américains, peuvent pas écrire Octets comme tout le monde (ou presque...) Bon, là c'est un problème plus simple à tester. Jacques

Comme je l'ai écrit plus haut, il suffit de les arrêter une à une et de regarder avec la commande les connexions qui ont disparues. Ensuite, regarder l'appli et son paramétrage si le débit a significativement baissé. Si le NAS est accessible de l'extérieur, le proxy peut être utilisé par des hackers pour lancer des attaques ou naviguer en toute discrétion par exemple. A suivre...

Bonjour, Est-ce que tu utilises Docker ? Si oui, regarde quelles sont les applications qui fonctionnent dedans et arrête les une à une pour voir (toujours avec la même commande) si les connexions en ESTABLISHED liées à Docker disparaissent. Je n'utilise pas docker, mais il y a pas mal de monde qui s'en sert sur ce forum et on pourra t'aider en cas de problème de configuration. L'important est de trouver quelle application génère ces connexions, et probablement ce trafic en plus, pour ensuite pouvoir la corriger ou la supprimer si elle ne sert vraiment pas. Jacques

Bonjour, et désolé pour le retard. L'essentiel des connexions semble être causé par nginx (en proxy ?) et docker-proxy et aussi DownloadStation. Si le proxy est ouvert, alors il est possible qu'il serve à pas mal de personnes à l'extérieur. Dans les programmes qui ont des connexions ouvertes, on ne voit que ceux-là pour le moment : docker-proxy nginx: worker synodlwget (DownloadStation) sshd (en local uniquement) Le plus simple est de couper une à une les VM qui sont gérées par Docker (si le nom docker-proxy n'est pas significatif pur isoler la VM) et de regarder ce que ça donne au niveau trafic. Jacques

La commande netstat existe sur Synology. Un netstat -lataupe (le second a n'est la que pour se souvenir de la commande, un autre façon de s'en souvenir mais moins élégante est -lapute) en root dans un console SSH devrait indiquer quelles sont les connexions établies, et éventuellement trouver les programmes actifs qui ne devraient peut-être pas y être (présence de trojans ou de virus au cas où). Selon les résultats, on pourra aller plus loin. Jacques

Bon, c'était plus simple effectivement... Ça servira peut-être à d'autres les idées développées ici. Bonne fin de journée Jacques

Bonjour L'idée d'Evotk (sauf erreur d'interprétation) n'est pas de rajouter un disque, mais d'utiliser un disque sur lequel tu installes la même version de DSM. Ensuite, quand tu veux tester une mise à jour, tu déconnectes tous tes disques, insère ce disque à la place et teste cette mise à jour sur ce disque. Si tout se passe bien, tu peux raisonnablement penser que ce sera la même chose sur la version "utile" de ton NAS. Dans ce contexte, il est intéressant d'installer les packages dont tu as vraiment besoin (surtout pour docker et la gestion des caméras éventuellement), bref tout ce que tu considères comme critique pour le bon fonctionnement du NAS. Jacques

Le paramètre a disparu de la configuration en 6.2, auparavant il était dans Panneau de configuration / Réseau / Interface réseau / Modifier / Activer Jumbo Frame Ceci permettait de modifier le MTU. En 6.X, le chemin est le même mais le nom est devenu Configurer manuellement la valeur de la MTU. Si la valeur est différente, on peut rencontrer des soucis (je l'ai vécu) bien qu'en théorie la valeur du MSS étant échangée à la connexion entre les PC on ne devrait pas dépasser celle du MTU... mais bon, ça n'a pas l'air d'être vrai dans tous les cas. Les switches gigabit SOHO ne permettent souvent pas de laisser passer autre chose que 1508 octets (soit un MTU de 1500) par trame. Tu peux utiliser l'outil iperf3 pour faire des tests entre les différents PC (une version Windows existe, pour linux le paquet iperf3 est disponible pour la plupart des distributions, et pour Synology, tu peux trouver la version correspondant au DSM que tu utilises ici : www.jadahl.com/iperf-arp-scan/ (ce qui évite d'installer docker comme indiqué dans les pages qui suivent). Liens vers une page d'explication sur l'usage d'iperf : https://www.cachem.fr/iperf-routeur-synology/ https://aradaff.com/tester-son-reseau/ Ça permettra d'avoir des valeurs précises. Maintenant, si le transfert décroit après un certain temps, il faudra regarder les options de iperf3 pour lancer la commande sur une durée plus longue (par défaut 10 paquets d'environ 100Mb en 10 secondes. Ne pas oublier d'ouvrir le port utilisé par iperf3 (5201 par défaut) dans le(s) pare-feu(x) traversé(s). Jacques

Bonsoir, Est-ce que les Jumbo Frames n'auraient pas été activées dans la configuration du Syno (et pas pour le reste du réseau, switch compris) ? Ou l'inverse, activées sur les PC mais pas sur le NAS ? Ça pourrait être une piste, sur les gros transferts,le fait d'utiliser des trames dont la taille n'est pas standard entraîne un échec de transport, et une réémission qui sera de nouveau un échec, etc... Autre possibilité, un MTU incohérent sur les équipements réseau ou les interfaces (1500 pour ethernet). A vérifier Jacques

Bon, c'est en route en ce cas. Le disque 1 peut être réutilisé (provisoirement) pour archiver des données (après reformatage) présentes sur le NAS dans l'attente du transfert sur le raid reconstruit ; idem pour le disque 3 ensuite, ce qui fait tout de même 4To pour récupérer les données non encore sauvegardées. Avec un peu de chance (pas de panne critique avant le re-transfert des données vers le NAS et son nouveau raid), ça devrait permettre de tout récupérer sans trop de mal. On peut insérer le disque dans un boîtier USB (ou un adaptateur) ou en l'ajoutant provisoirement dans un PC de bureau et en le reformatant. À suivre donc. Jacques

À l'exception des disques B / E / F et D malgré une erreur de lecture, les autres disques présentent des signes d'erreur : sda : secteurs réalloués = 6 sdc : secteurs réalloués = 1 Ce n'est pas encore critique, on est loin du seuil, mais ça correspond justement à la position des disques "mal positionnés" dans le raid logiciel (mdadm n'a pas de disque 0 et 2 pour le périphérique md2, qui est volume1). Je n'ai pas trouvé sur le Syno un fichier de configuration pour mdadm, le scan doit être refait à chaque démarrage. Je suppose que tu as déjà redémarré le NAS, mais je pense que c'est à refaire pour permettre de retrouver un emplacement normal des disques dans le raid md2. Maintenant, il y a 2 disques qui commencent à donner des signes de faiblesse, il serait prudent de commencer à sauvegarder l'ensemble (le raid 5 permet la perte d'un seul disque, et comme la loi de Murphy fonctionne toujours très bien...). Personnellement, je procéderai ainsi : Redémarrage du NAS pour voir si le RAID est vu de nouveau dans un état correct Remplacement du disque en première position (sda, à vérifier avec le n° de série visible dans le résultat de la commande mdadm) Reconstruction du raid automatiquement (ça peut prendre plusieurs heures, voire des jours, mais le disque ne fait que 2 To tout de même) Une fois le raid reconstruit, arrêt du NAS Remplacement du disque en position 3 (sdc, à vérifier selon le n° de série) Reconstruction du raid automatiquement Redémarrage complet du NAS et vérification de l'état du raid dans le gestionnaire de disques Si au point 1 le volume est toujours en lecture seule, on peut tout de même tenter le point 2 car je pense que le volume est simplement monté en lecture seule dans ce cas par sécurité (on peut le vérifier avec la commande mount | grep volume1 qui indique entre parenthèse les options de montage, rw pour lecture/écriture ou ro pour lecture seule). root@Maison:/etc# mount | grep volume /dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) Si c'est bien le cas, le raid devrait se reconstruire tout de même car la réparation se passe directement au niveau du disque et non pas au niveau du système de fichiers. Jacques

Ça ressemble plus à une incohérence du DSM qu'à une panne réelle... Dans l'état des disques LVM, je ne vois aucune erreur. Et dans l'état du raid, les 3 volumes sont vus en état clean (l'indication degraded pour md0 (DSM) et md1 (swap) est normal, le raid étant prévu pour prendre en compte tous les disques "gérables" dans la NS émulé par Xpenology (soit 12 disques dans ce cas). Il y en a donc 6 qui sont absents. La seule anomalie que je vois est la numérotation des disques du raid md2 (accessible via LVM via vg1000 est monté dans /volume1. Les disques 0 et 2 (partitions sda5[0] et sda5[2]) sont absents et remplacé par les disques 6 et 7 (partition sda5[6] et sda5[7]), ce qui semblerait indiquer que ces disques ont été vus manquants à un moment et détectés à nouveau en remplacement par les disques 6 et 7. Ceci n'est pas normal, et peut être la cause de l'erreur du DSM. Un test SMART sur les disques serait intéressant, ou au minimum l'état de santé de ceux-ci. Tu peux déjà donner le résultat de cette commande : for DISK in /dev/sd[a-z] ; do echo $DISK ; smartctl -d sat -i -A $DISK ; done (c'est une boucle qui afficher le nom du disque, les informations et le statut SMART de chaque disque présent dans la machine). Jacques

Bonjour, J'ajouterai à la demande de Nicoueron le contenu du fichier mdstat (résultat de la commande en SSH 'cat /proc/mdstat') puisqu'il s'agit d'un raid SHR (donc raid Soft sur LVM) ainsi que l'état des volumes logiques (commandes lvm suivies des options lvscan / pvscan / vgscan / vgdisplay) soit pour la 2ème commande : lvm pvscan. Ça permettra de savoir (peut-être) ce qui est vu en faute. Tu peux aussi ajouter le résultat de la commande mdadm --detail /dev/md* (toutes les commandes sont à lancer sous le compte root). Merci

Bonjour, Tout à fait d'accord avec Nicoueron, en Gb/s les 8 fils sont utilisés (2x2 dans chaque sens). L'avantage du Gb est qu'on peut connecter directement les 2 machines avec un câble droit ou croisé peu importe, l'interface s'adapte. Comme tu semble avoir un routeur entre, il y a au moins 1 câble qui devrait marcher pour faire un test en direct sans passer par le switch. Ensuite, tu pourras aviser selon les résultats. Jacques

Bonjour, Pas vraiment testé, mais j'ai déjà installé MacOS sous VirtualBox, donc en principe ça peut se faire en VMM. En fait, depuis que Apple utilise des processeurs Intel, la virtualisation est envisageable. Mais comme le dit Nicoueron, la gestion du clavier sera une émulation mais les touches Win devaient pouvoir se configurer en touches spécifiques MAC. Reste la souris qui est différente aussi... Ça vaut le coup de tenter de toute façon. Jacques

Bonjour, Si la partition 1 n'est pas en faute, tu peux démarrer l'ancienne VM en lui ajoutant un lecteur de CD et en chargeant dans ce 'lecteur" une iso du type RescueCD qui offre tous les outils pour accéder au raid soft. Ensuite, monter la partition du "disque dur" (le vmdk) devrait être possible et de là lire les fichiers, si rien n'est cassé dans l'image. Jacques

Bonjour, je n'ai pas de tuto, à part la documentation Vmware disponible. À priori c'est avec Workstation et non un ESXi, ce que je connais encore moins (j'ai quasiment toujours utilisé Vmware en environnement pro). Une VM dispose d'une carte réseau virtuelle (à choisir parmi celles compatibles avec le DSM sinon la connexion échouera car le matériel ne sera pas reconnu), typiquement e1000e, cette carte est connecté à un switch virtuel en ESXi (en WS, c'est probablement simplement à une pseudo carte VM1 ou VM8 network si je me souviens bien), et ce switch (ou cet accès réseau) est connecté à une ou plusieurs interfaces physiques réelles. Ce sont ces dernières qui ont accès au vrai réseau et obtiennent les adresses IP en DHCP (elles sont "transparentes" aux trames IP venant de la VM. Dans les paramètres de WS, ces 2 réseaux n'ont pas les mêmes caractéristiques, l'un est connecté au réseau physique (VM1 si je me souviens bien), l'autre reste en interne (VM8) et permet d'interconnecter des VM entre elles. La 1ère chose à faire est de vérifier quel est le réseau à utiliser (VM1 ou VM8) pour être sûr d'avoir une chance que la VM puisse atteindre le réseau physique, et que le réseau est bien dans l'état "connecté à la mise sous tension). Ensuite, vérifier que le pare-feu Win10 ne bloque pas ces interfaces ou le désactiver provisoirement. Dans ce forum, tu trouveras comment déclarer un port série à ta VM pour et le rediriger vers un fichier texte pour voir les traces du démarrage. Dans ces traces, tu verras normalement la configuration réseau apparaître, ce qui te donnera l'indication fiable à la fois de la connexion au réseau et de la réponse de ton serveur DHCP (sur la ta box en principe). Tu peux aussi réserver l'adresse de la VM dans ton serveur DHCP en associant l'adresse MAC définie dans les paramètres de la carte réseau de la VM (on peut la fixer manuellement dans un ESXi, sous WS pas de souvenir). De cette façon, tu es sûr que la VM aura toujours la même adresse (ce qui est plus pratique pour un serveur). Une fois le VM démarrée, et le DSM actif en principe, vérifie que l'adresse est encore identique, en principe un serveur DHCP redonne la même adresse tant que le bail n'est pas arrivé à expiration et que l'adresse MAC est identique. Si à ce point l'adresse disparaît pour redevenir une adresse APIPA, c'est que la VM n'a plus un accès correct au réseau. Dans ce cas, on en revient à un problème de configuration du DSM avec des valeurs de réseau non compatibles avec la box (ce qui peut être, comme indiqué dans mon post, un numéro de Vlan associé dans la config (et ignoré du loader) ou des jumbo frames activées , mais pour du DHCP ça devrait passer je pense, la taille des trames étant loin d'être conséquente dans les échanges. Pour lever le doute, on peut installer Wireshark sur le PC et tracer en se connectant à l'interface utilisée par la PC pour accéder au réseau physique 'LAN de la box). Ça demande un peu d'expertise, mais il est assez facile de faire un filtre (à la capture : host = @IPdeLaVM) et de regarder dans les trames si on voit un numéro de vlan (autre que 0). Sinon, ou si c'est le cas, il faut envisager : 1) de démarrer la VM avec un CD de boot (image ISO, donc rajouter un lecteur de CD virtuel) de type RescueCD pour avoir accès dans la console au système du DSM (1ère partition du "disque"), en principe /dev/md0, mais comme le CD ne lit pas le fichier mdadm.conf, il peut s'agir de /dev/md127 et le monter dans /mnt par exemple. Ensuite, accéder au dossier etc/sysconfig/network-scripts/ depuis le point de montage et regarder le contenu du fichier ifcfg-eth0 (si une seule interface). Si tu arrives à ça, on pourra aviser ensuite. 2) Recréer une autre VM à partir du template fait par Nicoueron et y rattacher ton disque virtuel (en principe on affecte un ou plusieurs disques en RDM) à une VM. En restaurant la sauvegarde de la config de la 1ère VM, ça devrait aller assez vite. 3) Démarrer la VM en mode installation (il faut être rapide au moment du choix dans le menu de Grub) et faire une réinstallation de la partie DSM et reconfigurer le tout. Bon courage, et prend le temps avant de faire des choix critiques. À ce stade les données sont intactes, dans les réinstallation il ne faut surtout pas valider le formatage de la partition de données, donc bien lire les messages. Jacques