JacquesF

Bon, en ce cas on peut tenter de retirer sda1 de la configuration du raid md0. Personnellement j'essaierai de faire ça : - Déclarer le disque /dev/sda1 de /dev/md0 comme défectueux mdadm --manage /dev/md0 --faulty /dev/sda1 - Enlever ce disque du raid mdadm --manage /dev/md0 --remove /dev/sda1 Ensuite voir l'état du raid avec : cat /proc/mdstat Et si le raid semble être OK avec les disques présents pour md0, tenter de le remonter une nouvelle fois mount /dev/md0 /mnt/nas

Tu peux donner le résultat de : vg lv Je pense que ton volume de données est intact, mais j'aurais aimé en être certain, d'où l'essai pour le monter. Sinon, selon que tu possède ou non une sauvegarde de ta configuration (tout n'est pas enregistré, il manque pas mal de paramètres sur les autorisations d'accès si je me souviens bien, j'ai restauré un DS110j il y a peu et j'ai du utiliser mes copies d'écran pour récupérer le tout). Depuis, je me fait un fichier PDF avec les copies de chaque écran important), on peut : - soit réinstaller le DSM en refusant bien entendu de formater la partition de données si on le propose - soit tenter de retirer le disque dsa1 du raid md0 pour accéder au raid et faire les corrections de la mise à jour. Ce qui m'ennuie beaucoup dans ce cas, c'est qu'il manque un disque à priori (/dev/sdg1 qui est listé dans le superblock et ne semble pas correspondre à sdh1). Si 2 disques manquent, on commence à prendre des risques, même si pour le DSM on est sur du raid 1 (mirrorring) et que les données sont donc dupliquées sur tous les disques.

J'ai les doigts qui sont dyslexiques... btrfs sera mieux que brtfs

Il n'y a pas d'autres commandes pour configurer le raid soft. Le risque est de perdre les données du raid... ce qui n'est pas rien. On va commencer par vérifier que les données sont toujours présentes : mount -t brtfs -o ro /dev/mapper/vg1000-lv /mnt/nas et ensuite le résultat de la commande : ls -l /mnt/nas Si tu y trouves les répertoires de tes données (en principe /volume1) on est à peu près tranquille pour y accéder ensuite. Ensuite, démonte le volume : umount /mnt/nas Et la question qui tue ? as-tu une sauvegarde de ta configuration du DSM ?

Si je lis bien ça, il y a un superblock de créé pour sdg1 mais aucune données dedans. Je n'ai pas une énorme habitude de mdadm, et ce sont des commandes à risque... Ce que j'ai l'impression de comprendre en voyant le résultat des commandes est que : - la référence aux disques dans le superblock indique les affectations avec le NAS fonctionnant correctement (disques A à G soit 7 disques) - le DVD Ubuntu est vu sur le disque sdg, ce qui explique que sdg1 soit de type vfat (est-ce une clef USB ?) et donc ne comporte pas d'informations sur le raid Peux-tu me dire ce que contient le fichier mdadm.conf de ton Ubuntu (il peut ne pas exister) : cat /etc/mdadm.conf

Bon, sda1 n'est as en forme et sdg1 qui n'a pas été affiché dans le raid md0 (dans mdstat) est bien listé dans le superblock comme faisant partie du raid. Tu peux donner le résultat de mdadm -E /dev/sdg1 Si c'est du même type que les autres disques, on va essayer de le rajouter dans le raid et de déclarer sda1 en faute, ce qui devrait permettre de monter le raid. Maintenant, c'est quand même étrange que ce disque soit en faute si tu n'as rien fait d'autre qu'installer le DSM.

Que donne la commande : mdadm -E /dev/sd[a-f]1 (-E pour examine, sd[a-f] pour les disques compris entre sda et sdf et le 1 qui suit pour la partition 1)

A priori il manque le disque H dans le raid md0 (pas de sdh1 pour la ligne md0). Le raid est bien détecté, donc est-il monté ? Donne la sortie de la commande mount directement sans rien filtrer (pas de grep) , on verra ce que ça donne.

Essaye autrement : mount -t ext4 /dev/md0 /chemin/vers/point/de/montage (éventuellement /mnt/nas) Et sinon, donne le résultat de la commande : cat /proc/mdstat

J'ai modifié ma réponse ci-dessus, regarde si tu es concerné

Bon, à priori ton raid est monté... Le système (DSM) est présent sur tous les disques (sauf ceux de cache et la clef USB bien sûr) dans la partition 1 (taille 2,4 Go). C'est à dire, si je n'en ai pas oublié : sda1 / sdb1 / sdc1 / sdd1 / sde1 / sdf1 / sdh1 Le raid est assemblé correctement, puisqu'il y a un device md0 créé : Disque /dev/md0 : 2,38 GiB, 2549940224 octets, 4980352 secteurs La dernière commande donnée ne peut effectivement rien donner puisque le raid (et le LVM) ont l'air de fonctionner et que le grep filtre sur les périphériques de type disque (sdX), sort ne fait que trier pour faciliter la lecture. Si tu tapes la commande mount | grep /dev/m on ne va afficher que les périphériques de type mdX (raid soft) et mapper (lvm). Sur mon NAS, j'ai ce résultat (sur le LiveCD il est possible que tu n'aies rien, pas grave) : root@Maison:/var/log# mount | grep /dev/m /dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered) /dev/md3 on /volume2 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) /dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) Si ceux-ci sont montés, il y aura une sortie à cette commande, sinon il faudra monter le DSM (/dev/md0) à la main pour y accéder. Si rien n'est monté, utilise cette commande pour accéder à ton DSM (en root) : mkdir /mnt/dsm mount /dev/md0 /mnt/nas Dans le cas où le raid a été monté automatiquement par le LiveCD, il faut remplacer /mnt/nas dans les commandes qui suivent par le chemin qui correspond à md0 dans la sortie de la commande mount | grep /dev/m Si la commande mount éventuelle ne retourne pas d'erreur, tu devrais pouvoir afficher ton fichier VERSION avec la commande : cat /mnt/nas/etc/VERSION ou cat /chemin/vers/point/de/montage/de/md0/etc/VERSION Si le contenu semble correct (entre autre le productversion=6.X.X qui doit être la version que tu as installée), on va modifier la racine du système pour que les commandes des tutos ne soient pas à transposer à chaque fois (pour trouver les fichiers qui ne sont plus positionnés depuis la racine du DSM mais depuis le point de montage (/mnt/nas + le chemin DSM)) avec la commande : chroot /mnt/nas Si il n'y a pas d'erreur, tu peux maintenant te placer dans le répertoire etc du DSM avec la commande : cd /etc Vérifier le fichier VERSION avec : cat VERSION Si tout est OK (même contenu qu'avant), applique la procédure de nettoyage (fichier VERSION et répertoires de stockage des mises à jour à nettoyer). Ensuite, sort de l'environnement "chrooté" avec la commande : exit Démonte le DSM avec : umount /mnt/nas Croise les doigts et redémarre le tout... puis réinstalle le DSM que tu avais avant la migration (et bien entendu ne pas répondre OK si on propose de formater la partition de données !). Jacques

Bonjour, Le message "assembly aborted" est donné suite à quelle commande (je suppose que c'est mdadm) ? Si c'est le cas, c'est qu'un des disques du RAID est en faute ou vu manquant. Est-ce que tous les disques sont connectés lorsque tu démarre le linux de secours ? (RescueCD est très bien car tout ce qu'il faut pour monter un raid ou un LVM est présent de base). Le raid SHR est une combinaison de raid soft (géré par mdadm) et de volumes dynamiques (gérés par vgchange). Le but de la manip est de monter la grappe raid (commande mdadm -Asf) suivie si tout s'est bien passé (condition indiquée via &&) par l'assemblage des volumes (commande vgchange -ay). Si un disque manque, le raid ne peut pas être monté (excepté en dégradé si seul un disque manque, mais dans ton cas ça pourrait suffire). Si le raid n'est pas monté, le volume ne peut pas être trouvé et rendu accessible par LVM. Ce qui est possible c'est que si tu démarre le système via une clef USB, celle-ci soit vue comme un périphérique (/dev/sda peut-être ?) et pose un problème lors du scan des périphériques raid. Peux-tu donner le résultat des commandes suivantes (à faire en tant que root (donc sur une version basée sur debian/ubuntu après la commande sudo -i) : blkid fdisk -l mount | grep /dev/sd | sort Avec ça; on devrait pouvoir identifier quels sont les disques réellement prévus pour être dans le raid SHR, et tenter d'assembler le raid de manière manuelle. Jacques

Dans le panneau de configuration, partie "Mise à jour et restauration", il suffit de choisir les mises à jour manuelles et dans les options de décocher la recherche automatique. En principe, si rien n'est cherché, rien ne sera trouvé non plus... et de là ne sera proposé. Jacques

Je n'ai jamais utilisé Synology Assistant sous Windows, mon PC est sous Linux et aucun soucis avec la 6.2 Si on renvoie vers le navigateur, en principe la page devrait être la même ou presque. Avec une version 6 de l'assistant, ce qui est certain c'est que le compte à créer est libre, pas d'admin imposé. Vérifier la version avec l'icone "i" en haut à droite, chez moi c'est la 6.2-24922. Jacques

A mon avis, la version du Synology assistant n'est pas à jour. J'ai refait une installation récente en 6.2 sans aucun soucis en créant le compte voulu. Jacques

Bonjour, Dans ce cas, une réinstallation du DSM serait la chose la plus efficace je pense. Tant que l'installeur ne propose pas de formater la partition de données, il n'y a pas de risque (à condition de rester dans une version compatible). Si la configuration n'a pas été sauvegardée, des copies d'écrans à faire pour ce qui est visible dans l'interface, pour le reste ce sera un effort de mémoire et du temps à y passer sans doute. Bon courage Jacques

Le fichier le plus souvent intéressant est messages (et éventuellement les archives compressées .N.xz), ensuite dmesg peut aussi contenir des traces mais cela concerne plutôt le démarrage en principe, je doute que les traces du noyaux soient intéressantes (kern.log). Si la VM est de type linux, on retrouvera dans /var/log d'autres fichiers de traces qui seront propres à la machine. Si la clef disparait dans la VM et pas dans l'hôte (le NAS), alors on est sur un problème de virtualisation. Jacques

Si la clef marche bien en USB2 et que c'est surtout un problème de port disponible, ça vaut peut-être le coup de tenter de la connecter au port USB3 via une rallonge USB2, de cette manière le débit sera celui de l'USB2 et si ce n'est pas un problème de pilote, ça devrait régler le problème. Ça vaut le coup d'être tenté au moins pour déterminer ce qui est en cause. Jacques

Bonsoir, Ça sent un pilote pas très à jour, ou une clef pas très fiable... Il serait intéressant de regarder dans les logs de la VM et aussi dans ce du NAS ce qui se passe à ce moment, histoire de départager qui de l'hôte ou de l'invité est en cause (je pencherai plus pour le NAS). Pas d'autre idée pour le moment Jacques

Bonsoir, Jamais eu l'occasion de le faire. Les disques sont identifiés dans le cas d'un raid soft (Raid ou SHR) par une information stockée en toute fin de disque (superblock). Elle indique à quel grappe il appartient et permet ainsi de construire le raid directement au démarrage. En principe, je ne vois pas en quoi l'ordre des disques poserait un problème pour identifier les membres du raid puisque c'est justement la présence de ce bloc qui permet de détecter quels disques en font partie et de construire la grappe au démarrage. Dans le cas d'un raid matériel, là cela dépendra du contrôleur, mais je doute que la position des disques soit vraiment critique. Mais je n'ai aucune certitude là-dessus. Vues la quantité et la taille des disques, je doute qu'une sauvegarde du contenu soit facile à faire... Mais personnellement, j'arrêterai le NAS, retirerai tous les disques en identifiant leur position, mettrai 3 ou 4 petits disques de récupération et je ferai le test d'installer DSM, de créer le RAID en respectant le même type que le précédent, mettrai des données dessus et stopperai le NAS. Ensuite je ferai le test de déplacer les disques dans la grappe et de redémarrer le tout pour voir si je retrouve mes données de test. C'est nettement plus sûr ainsi. Au pire, avec 2 disques placés sur les 2 premiers ports de la carte on peut faire le test, à positionner n'importe où ensuite sur les ports de la carte. Mais si c'est un raid soft géré donc par mdadm (natif Synology et non pas un contrôleur RAID externe), je suis quasi certain qu'on retrouvera les données après ce test. Ensuite, selon les résultats, il sera temps de choisir le mode d'extension à suivre. Jacques

Je n'ai jamais tenté directement ce saut, mais tant qu'on ne propose pas de formater la partitions de données... tout va au mieux. Maintenant, la sauvegarde de la configuration est à faire, et même des copies d'écran car on ne récupère pas tout dans le cas d'une réinstallation. Mais si ça migre correctement, en principe pas besoin, mais ça c'est le risque. Regarde sur le forum anglais si quelqu'un a déjà fait ça. Pour le mot de passe, s'il n'y a pas trop de disques, ça peut se tenter en bootant sur une distribution linux (genre rescuecd) et en montant la partition /dev/md0 (en principe ce genre de distribution est capable de détecter raid et LVM (ce qu'est le SHR) directement). Sinon, il y a une procédure sur le site de Synology pour récupérer ses données dans le cas d'un crash DSM, on peut s'en inspirer pour les commandes à saisir. J'ai déjà fait une réponse concernant un mot de passe dans un autre Post en indiquant la marche à suivre (édition du fichier shadow) et en donnant une chaîne chiffrée correspondant au mot de passe "admin". Fais une recherche dessus. Jacques

Bonjour, Si c'est un vrai NAS Synology, il y a normalement un bouton de reset pour revenir à une configuration implicite. A chercher dans la documentation du NAS. De même, avant d'installer une autre version de DSM, vérifier qu'elle est compatible avec le NAS (perso j'ai aussi un DS110j dont la dernière version est la 5.2), ce qui ne me gêne pas, car il n'est pas relié au web). Et comme je l'ai déjà écrit plus haut, je ne sais pas d'expérience si l'installation d'une version supérieure réinitialisera le compte admin (qui ne sert plus si je ne m'abuse en DSM6). Une fois le mot de passe remplacé, activer SSH et mettre en place une authentification par clefs sur le compte root permettra de régler les problèmes de ce type à venir. Jacques

Bonjour, Rien n'empêche de créer une page web distribuée par un serveur Web sur le NAS et consultée depuis Windows, ou n'importe quel autre client. Maintenant, monitorer correctement des partages réseaux, ça ne sera pas évident, les protocoles de partages n'offrant en général pas les services nécessaires au suivi des modifications. Le DSM sait offrir des partages CIFS (ou Samba/SMB) et NFS. Via un serveur (dans docker ou autre), on peut avoir du WebDav. Reste à trouver un client capable de suivre les modifications sur l'un de ces trois protocoles. Jacques

Bonjour, Directement sur le NAS, la commande inotifywait devrait faire ce qu'il faut... Voir cette page pour l'exploiter, ensuite il faut coder un petit script et le lancer soit avec rc.local, soit par une tâche programmée, au démarrage du NAS. https://stackoverflow.com/questions/8699293/how-to-monitor-a-complete-directory-tree-for-changes-in-linux Jacques

Bonjour, Les versions sont à récupérer sur le site de Synology : https://archive.synology.com/download/Os/DSM Concernant le SC1430, il faut faire une recherche sur le forum anglais, au sujet des mises à jour, et chercher dans les réponses si quelqu'un a déjà déclaré un matériel de ce type comme compatible. Sinon, installer ESXi dessus (de mémoire je l'avais fait il y a 4 ou 5 ans sur des serveurs de ce type (avec proc Intel et non AMD) et virtualiser le DSM (voir le forum pour récupérer des VM prêtes à l'emploi en ce cas. Jacques