Migration OMV 4-> 6 perte de mes données 4 disques en raid 5

Tags: #<Tag:0x00007f4690fbe158>

blkid

/dev/sdd: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="f4d8aaae-4f6d-40f6-a9f3-38a1aedfa0c8" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sde1: UUID="08c3871d-7232-4b4f-9acc-8f521db0dc1a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ab072bde-01"
/dev/sde5: UUID="4ea674ac-b4cb-40ef-9922-56260fa48d88" TYPE="swap" PARTUUID="ab072bde-05"
/dev/sdb: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="a65a3112-c7db-a0e4-03e7-8f4f19d265e4" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sda: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="163f9575-1204-c670-407f-a9648abb5acc" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sdc: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="7a286c96-71b2-5fca-06b5-578b07e937d7" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/md127: LABEL="Fil1" UUID="dad71d93-597e-435e-b28f-10ac4bd46498" BLOCK_SIZE="4096" TYPE="ext4"

findmnt

TARGET                       SOURCE     FSTYPE     OPTIONS
/                            /dev/sde1  ext4       rw,relatime,errors=remount-ro
├─/sys                       sysfs      sysfs      rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security     securityfs securityfs rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup           cgroup2    cgroup2    rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
│ ├─/sys/fs/pstore           pstore     pstore     rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/bpf              bpf        bpf        rw,nosuid,nodev,noexec,relatime,mode=700
│ ├─/sys/kernel/debug        debugfs    debugfs    rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/tracing      tracefs    tracefs    rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/config       configfs   configfs   rw,nosuid,nodev,noexec,relatime
│ └─/sys/fs/fuse/connections fusectl    fusectl    rw,nosuid,nodev,noexec,relatime
├─/proc                      proc       proc       rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc systemd-1  autofs     rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_
├─/dev                       udev       devtmpfs   rw,nosuid,relatime,size=1879204k,nr_inodes=469801,mode=755,inode64
│ ├─/dev/pts                 devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/shm                 tmpfs      tmpfs      rw,nosuid,nodev,inode64
│ ├─/dev/mqueue              mqueue     mqueue     rw,nosuid,nodev,noexec,relatime
│ └─/dev/hugepages           hugetlbfs  hugetlbfs  rw,relatime,pagesize=2M
├─/run                       tmpfs      tmpfs      rw,nosuid,nodev,noexec,relatime,size=389492k,mode=755,inode64
│ ├─/run/lock                tmpfs      tmpfs      rw,nosuid,nodev,noexec,relatime,size=5120k,inode64
│ └─/run/rpc_pipefs          sunrpc     rpc_pipefs rw,relatime
└─/tmp                       tmpfs      tmpfs      rw,relatime,inode64

mount

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1879204k,nr_inodes=469801,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=389492k,mode=755,inode64)
/dev/sde1 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=11413)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,relatime,inode64)

df

Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
udev                 1879204       0    1879204   0% /dev
tmpfs                 389492    2096     387396   1% /run
/dev/sde1           59279292 2964068   53271592   6% /
tmpfs                1947452       0    1947452   0% /dev/shm
tmpfs                   5120       0       5120   0% /run/lock
tmpfs                1947452       0    1947452   0% /tmp

lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    1  2,7T  0 disk
└─md127   9:127  0  8,2T  0 raid5
sdb       8:16   1  2,7T  0 disk
└─md127   9:127  0  8,2T  0 raid5
sdc       8:32   1  2,7T  0 disk
└─md127   9:127  0  8,2T  0 raid5
sdd       8:48   1  2,7T  0 disk
└─md127   9:127  0  8,2T  0 raid5
sde       8:64   1 58,7G  0 disk
├─sde1    8:65   1 57,7G  0 part  /
├─sde2    8:66   1    1K  0 part
└─sde5    8:69   1  975M  0 part  [SWAP]

Les données sont probablement toujours dans l’ensemble RAID /dev/md127. blkid indique qu’il contient un système de fichiers ext4 étiqueté « Fil1 ». Pour y accéder il faut qu’il soit monté. Je suppose qu’on ne peut pas se contenter de le monter n’importe où avec mount ou une ligne dans /etc/fstab, mais ne connaissant pas OMV, j’ignore comment il faut faire pour qu’il le prenne en compte, s’il y a un point de montage dédié ou s’il faut le déclarer quelque part dans l’interface graphique.

Par contre je ne vois pas comment il pourrait y avoir « 4 répertoires racines » puisqu’un système de fichiers ext4 n’a qu’un seul répertoire racine. Est-ce que tu voulais dire « 4 répertoires à la racine » ?

Note : le nom « md127 » est probablement attribué au lieu du nom d’origine « md0 » parce que le nom d’hôte spécifié lors de la nouvelle installation diffère de l’ancien.

@PascalHambourg
oui effectivement il y avait 4 répertoires à la racine nommé « Média », « Setup », « Data » et « Perso »…

c’est justement eux que j’aimerais retrouver…
mais hélas je ne suis pas du tout compétent dans ce domaine et ce que tu me raconte est assez compliqué pour moi…
je vais essayer de comprendre en regardant les définitions des principes que tu utilise…

Dans un premier temps tu peux monter temporairement le volume avec

mount /dev/md127 /mnt

et vérifier que les données sont bien présentes dans /mnt.
Mais je ne sais pas comment faire pour qu’OMV utilise le volume comme avant.

@PascalHambourg
est ce que cette commande ne risque pas de mettre mon système dans un état bloqué?
mount /dev/md127 /mnt

je me suis renseigner (avec mes maigres compétences) par exemple ici et de ce que je vois cette commande fonctionne pour principalement des partitions sur un disque…

or mon cas est que j’ai 4 disques identiques montés en raid5 et je pense que le problème viens plus de la perte de référencement (?) synchronisation (?) inscription (?) ou autres (?) qui fait que Debian ne les reconnais plus, ou ne les interroges plus (?)

cela dit j’ai très envie d’essayer ta commande car si sa se trouve elle donne le résultat attendue… mais si il y a un risque pour mes photos/vidéos de mariages et naissances d’enfants ça me fait prendre quelque précautions…

du coup en continuant à chercher des solution je suis tombé sur ce cite: https://www.deltasight.fr/remonter-raid-mdadm/ … qu’en pensez vous?

d’autre part voici d’autres logs qui peuvent servir:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# sfdisk -l
Disk /dev/sda: 2,73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: WDC WD30EZRX-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/sdb: 2,73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: WDC WD30EZRX-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sdc: 2,73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: WDC WD30EZRX-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sdd: 2,73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: WDC WD30EZRX-00S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sde: 58,69 GiB, 63023063040 bytes, 123091920 sectors
Disk model: SanDisk SDSSDP06
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xab072bde

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sde1  *         2048 121092095 121090048 57,7G 83 Linux
/dev/sde2       121094142 123090943   1996802  975M  5 Extended
/dev/sde5       121094144 123090943   1996800  975M 82 Linux swap / Solaris


Disk /dev/md127: 8,19 TiB, 9001374842880 bytes, 17580810240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1572864 bytes

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# blkid
/dev/sda: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="163f9575-1204-c670-407f-a9648abb5acc" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sdb: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="a65a3112-c7db-a0e4-03e7-8f4f19d265e4" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sdc: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="7a286c96-71b2-5fca-06b5-578b07e937d7" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sdd: UUID="f125d73b-17d5-0597-dd60-db60ff557073" UUID_SUB="f4d8aaae-4f6d-40f6-a9f3-38a1aedfa0c8" LABEL="OMV1:DdRaid5" TYPE="linux_raid_member"
/dev/sde1: UUID="08c3871d-7232-4b4f-9acc-8f521db0dc1a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ab072bde-01"
/dev/sde5: UUID="4ea674ac-b4cb-40ef-9922-56260fa48d88" TYPE="swap" PARTUUID="ab072bde-05"
/dev/md127: LABEL="Fil1" UUID="dad71d93-597e-435e-b28f-10ac4bd46498" BLOCK_SIZE="4096" TYPE="ext4"

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# mdadm --examine /dev/sda
/dev/sda:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : f125d73b:17d50597:dd60db60:ff557073
           Name : OMV1:DdRaid5
  Creation Time : Fri Oct 17 09:01:47 2014
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5860271024 sectors (2.73 TiB 3.00 TB)
     Array Size : 8790405120 KiB (8.19 TiB 9.00 TB)
  Used Dev Size : 5860270080 sectors (2.73 TiB 3.00 TB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=944 sectors
          State : clean
    Device UUID : 163f9575:1204c670:407fa964:8abb5acc

    Update Time : Fri Mar  3 10:58:06 2023
       Checksum : 93b64bad - correct
         Events : 1562

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
   
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# mdadm --examine /dev/sdb
/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : f125d73b:17d50597:dd60db60:ff557073
           Name : OMV1:DdRaid5
  Creation Time : Fri Oct 17 09:01:47 2014
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5860271024 sectors (2.73 TiB 3.00 TB)
     Array Size : 8790405120 KiB (8.19 TiB 9.00 TB)
  Used Dev Size : 5860270080 sectors (2.73 TiB 3.00 TB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=944 sectors
          State : clean
    Device UUID : a65a3112:c7dba0e4:03e78f4f:19d265e4

    Update Time : Fri Mar  3 10:58:06 2023
       Checksum : a71ebd45 - correct
         Events : 1562

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
   
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# mdadm --examine /dev/sdc
/dev/sdc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : f125d73b:17d50597:dd60db60:ff557073
           Name : OMV1:DdRaid5
  Creation Time : Fri Oct 17 09:01:47 2014
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5860271024 sectors (2.73 TiB 3.00 TB)
     Array Size : 8790405120 KiB (8.19 TiB 9.00 TB)
  Used Dev Size : 5860270080 sectors (2.73 TiB 3.00 TB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=944 sectors
          State : clean
    Device UUID : 7a286c96:71b25fca:06b5578b:07e937d7

    Update Time : Fri Mar  3 10:58:06 2023
       Checksum : 3fb246b6 - correct
         Events : 1562

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# mdadm --examine /dev/sdd
/dev/sdd:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : f125d73b:17d50597:dd60db60:ff557073
           Name : OMV1:DdRaid5
  Creation Time : Fri Oct 17 09:01:47 2014
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5860271024 sectors (2.73 TiB 3.00 TB)
     Array Size : 8790405120 KiB (8.19 TiB 9.00 TB)
  Used Dev Size : 5860270080 sectors (2.73 TiB 3.00 TB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=944 sectors
          State : clean
    Device UUID : f4d8aaae:4f6d40f6:a9f338a1:aedfa0c8

    Update Time : Fri Mar  3 10:58:06 2023
       Checksum : 8b1be759 - correct
         Events : 1562

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

petit ajout…

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~# mdadm --detail /dev/md127
/dev/md127:
           Version : 1.2
     Creation Time : Fri Oct 17 09:01:47 2014
        Raid Level : raid5
        Array Size : 8790405120 (8.19 TiB 9.00 TB)
     Used Dev Size : 2930135040 (2.73 TiB 3.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Fri Mar  3 10:58:06 2023
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : resync

              Name : OMV1:DdRaid5
              UUID : f125d73b:17d50597:dd60db60:ff557073
            Events : 1562

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd

de plus j’ais l’impression que mon problème est le même que ici: https://forum.hardware.fr/hfr/OSAlternatifs/Installation/recuperation-raid5-omv-sujet_76831_1.htm

Autre piste dans la log de la commande « blkid » je trouve [LABEL=« OMV1:DdRaid5 »] OMV1… est ce normale cette notation?

Pas plus que monter une clé USB. C’est toi qui vois.

Non, mount fonctionne avec n’importe quel périphérique bloc qui contient un système de fichiers : disque entier, partition, volume logique LVM, volume chiffré, ensemble RAID…

Pas montés. Assemblés. La notion de montage est réservée aux systèmes de fichiers.
A priori l’ensemble RAID n’est pas en cause, il est actif avec ses 4 disques. Il ne reste qu’à le monter.

Charabia sans queue ni tête.

Debian reconnaît parfaitement les 4 disques et l’ensemble RAID résultant. Il ne l’utilise pas parce qu’il n’a pas de raison de le faire tant que le système de fichiers n’est pas monté.

C’est lorsque l’ensemble RAID ne s’assemble pas, donc pas adapté ici.

En tout cas c’est le nom enregistré dans les méta-données de l’ensemble RAID, comme on peut le voir avec mdadm --detail. Le nom du système lors de la création de cet ensemble RAID était donc « OMV1 ». Quel est-il actuellement ?

hostname
root@pickwick:~# hostname
pickwick

Du coup, est- ce que se serait mieux si je renomme en OMV1? heuu ça se fait directement dans l’ihm web d’OMV?

Par expérience, il est préférable d’effectuer les opérations via l’interface d’OMV plutôt qu’en mode « console », parce qu’OMV utilise une BdD pour toute sa configuration… Reste à savoir ce qu’il te reste à faire pour reconfigurer ton système via cette interface.
Du coup, je pense qu’il serait plus judicieux de poser ton problème via le forum d’OMV car si ça peut te rassurer ça m’étonnerait que tu aies perdu ton RAID et son contenu.

Ou bien modifier le homehost de l’ensemble RAID en « pickwick ». Dans les deux cas ça attribuerait à l’ensemble RAID un nom /dev/md* et un alias /dev/md/homehost:nom correspondant mieux au système, mais j’ignore si ça change quelque chose pour OMV.

Aucune idée, je ne connais pas du tout OMV.

Pour le moment, sauf si j’ai loupé un épisode, on en est encore à monter temporairement le système de fichiers contenu dans l’ensemble RAID pour voir si les données sont présentes.

Oui OK, je voulais juste signaler qu’à terme, il faudra de toutes façons passer par OMV, pour ce qui n’est probablement qu’un problème de configuration d’OMV.

voila j’ai renommé en OMV1:
Capture d’écran 2023-03-04 174124

ca se fait directement dans l’IHM
et en SSH il à bien modifié car ca me donne le prompt:
root@omv1:~# hostname
omv1

mais bon, toujours rien de nouveau sur le raid, c’est les même logs…
j’arrive pas à me décider de faire ce que tu me conseil @PascalHambourg :
mount /dev/md127 /mnt

C’est pas de la confiance en toi (je n’ai certainement pas ton expertise), c’est plus le manque de courage de ma part…

Le homehost RAID est en majuscules, et je vois que le nouveau hostname est en minuscules donc ça ne correspond toujours pas.

Arf… pourtant au redémarrage il apparaît bien en majuscule dans l’IHM… dommage…

au niveau justement de L’IHM dans Stockage => Raid j’ai cet écran:
Capture d’écran 2023-03-04 181302
et quand je sélectionne la ligne du raid (en jaune) la trousse avec la croix blanche se dégrise et passe en bleue avec un message « Récupérer » …
C’est peut être la solution? mais je ne sais pas ce qu’il se passe derrière…
au niveau de la documentation: https://docs.openmediavault.org/en/stable/administration/storage/raid.html
Ca donne :

Recover
If the array comes from another linux server you can use this button to reassemble the array in the current server

ce qui se traduit:

Récupérer
Si le tableau provient d’un autre serveur Linux, vous pouvez utiliser ce bouton pour réassembler le tableau dans le serveur actuel

… je sais pas quoi faire…

dsl pour les réponses tardives, mais le site me restreint dans le nombre de réponse 1 toutes les 2 heures au max actuellement

Dans le doute, il vaudrait mieux t’adresser au forum d’OMV comme on te l’a déjà conseillé. Ça n’a rien à voir avec Debian.

j’ai fait un message sur le forum OMV officiel, mais je ne suis pas du tout bon en anglais c’est pour ca…

maintenant après une nouvelle nuit à stresser j’ai lancé la fameuse commande que tu m’a donnée dés le début @PascalHambourg
mount /dev/md127 /mnt

et voila ce que j’obtiens:
cd /mnt
root@omv1:/mnt# ls
aquota.group aquota.user Data Média Perso Setup
root@omv1:/mnt#

je vois bien mes répertoires: Data Média Perso Setup

je t’aime @PascalHambourg !!! :sweat_smile:

bon en allant dans l’IHM OMV toujours rien de changé… faut il faire quelque chose avant de reboot?

C’est à cet endroit là que OMV s’attend à trouvé tes datas ?

Avec des installation OMV ou autre Appliance software tel que les firewall comme Pfsense en règle générale il vaut mieux éviter au maximum le recours à la CLI, à moins d’utiliser une API prévu à cet effet.

N’y avait-il pas une procédure pour gérer la montée de version sur la documentation officielle ?
En règle générale il explique comment monter de version …

Au risque de me répéter, voilà un extrait de la FAQ RAID d’OMV :

Never mount a drive with anything other than the OMV web interface. This creates the necessary database entries to populate the device dropdown.

Donc je te conseille de le démonter ou de redémarrer, et de continuer à te faire aider sur le forum d’OMV.
J’ai vu que des gens t’avaient répondu : Sur ta 2e image du poste #3, dans « Stockage-Systeème de fichiers - Monter » on voit ton /dev/md127 [EXT4, 8,18 TiB] apparaître, et on te demande de le monter, mais tu réponds qu’il n’y a rien ???

d’abord dsl pour l’attente mais des problèmes de santé m’ont écarté du clavier :mask:

maintenant chose très curieuse sur l’image on a vu le md127 apparaitre, et quand j’y suis retourné je ne la trouvais plus…
que s’est il passé entre temps: beaucoup de manip en ssh…

je me suis dit que puisque c’est écrit de tout faire pas l’IHM, j’avais foiré un truc…
donc j’ai tout réinstallé, j’ai retrouvé le md127, que j’ai aussitôt monté via l’IHM…
et hop j’ai pu alors retrouver mes répertoires en recréant leurs alias…

ouf! c’est gagné car en activant samba j’y accède et je retrouve tous mes fichiers!!

ÉNORME MERCI à @pled, @Zargos, @Clochette et particulièrement à @PascalHambourg d’avoir pris le temps de vous intéresser à mon problème et de m’avoir guidé. Je vous suis très reconnaissant!