Impossible étendre partition (filesystem error en boucle)

[Zetsubou]

Souhaitant étendre le volume de mon NAS DS2413+ par le remplacement d'un WD RED 6To, par un modèle 8To de la même marque, impossible de pouvoir terminer l'extension après la vérification de cohérence de parité.

DSM me signale des erreurs dans le fichier de fichiers et me propose de redémarrer pour effectuer une correction.
- Volume statut NORMAL avant et après tentative de réparation.
- Vérification SMART en mode long - HDDs OK sous DSM avant et après tentative de réparation.
- Contrôle des HDDs individuellement sur une autre machine - 0 reconnexion et 0 bad block trouvé.

Redémarrage + tentative de correction (environ 5H chaque tentative). Toujours même résultat avec un message de DSM concernant une erreur de système de fichiers.

Tentative de réinstaller DSM en sortant 11 des 12 disques et en installant un spare dans le premier casier - DSM réinstallé, packages réinstallés et configuration remise.
Tentative de réinitialiser le système au bouton reset, même message d'erreur de système de fichiers après tentative de réparation du volume.

Même problème après installation du DSM 6.1.1-15101 Update 2 + 3ème tentative de réparation (toujours e2fsck+debugfs pendant environ 5H quand je monitore sous PuTTy).
Données parfaitement accessibles si l'on ignore l'erreur et que l'on ne redémarre pas comme demandé dans l'interface de DSM.
 

J'ai signalé le problème à l'assistance technique il y a désormais 10 jours ouvrés, sans réponse de leur part.

J'ai écrit une relance il y a 2 jours afin de savoir ce que je devais faire ou me donner un statut de ma demande auprès du service, sans réponse à l'écriture de ces lignes.

Modifié le 17 mai 2017 par Zetsubou

[Fenrir]

Peux tu nous indiquer la topologie de ton nas (avec 12 disques tout est possible).

Le plus simple est probablement de faire un cat /proc/mdstat

Pendant que tu es connecté e ssh, regarde les journaux (dans /var/log) et fais aussi un dmesg

[Zetsubou]

Pour la topologie.

On part sur 10 disques en WD RED 6Tb (casiers 1 & 2, puis 5 à 12), ainsi que deux disques en WD RED 8Tb (casiers 3 & 4 - remplacement des 6Tb les plus vieux de la grappe par de nouveaux HDDs depuis début 2017).

Ci-joint le résultat de MDSTAT et en pièce jointe un extract de la commande DMESG.
 

Citation

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md3 : active raid5 sdj6[15] sda6[12] sdb6[11] sde6[10] sdf6[9] sdd6[20] sdc6[19] sdg6[18] sdh6[17] sdi6[16] sdl6[14] sdk6[13]
      21488442624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]

md4 : active raid5 sdd7[13] sdg7[11] sdh7[10] sdi7[9] sdj7[8] sdl7[7] sdk7[6] sda7[14] sdb7[4] sde7[3] sdf7[2] sdc7[12]
      21488442624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]

md2 : active raid5 sda5[20] sdj5[23] sdk5[21] sdl5[22] sdi5[12] sdh5[13] sdg5[14] sdf5[17] sde5[18] sdd5[16] sdc5[15] sdb5[19]
      21436576128 blocks super 1.2 level 5, 64k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]

md5 : active raid1 sdc8[0] sdd8[1]
      1953398528 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4] sdf2[5] sdg2[6] sdh2[7] sdi2[8] sdj2[9] sdk2[10] sdl2[11]
      2097088 blocks [12/12] [UUUUUUUUUUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[11] sdd1[10] sde1[9] sdf1[8] sdg1[7] sdh1[6] sdi1[5] sdj1[4] sdk1[3] sdl1[2]
      2490176 blocks [12/12] [UUUUUUUUUUUU]

 

Pour les logs, je ne sais pas lesquels sont pertinents à vous transmettre ou à regarder, car je ne suis pas du tout spécialiste dans le monde Linux.
 

dmesg.txt

Modifié le 17 mai 2017 par Zetsubou

[Fenrir]

_____raid1__raid1__raid5__raid5__raid5__raid1
a6____md0____md1____md2____md3____md4
b6____md0____md1____md2____md3____md4
c8____md0____md1____md2____md3____md4____md5
d8____md0____md1____md2____md3____md4____md5
e6____md0____md1____md2____md3____md4
f6____md0____md1____md2____md3____md4
g6____md0____md1____md2____md3____md4
h6____md0____md1____md2____md3____md4
i6____md0____md1____md2____md3____md4
j6____md0____md1____md2____md3____md4
k6____md0____md1____md2____md3____md4
l6____md0____md1____md2____md3____md4

La fin du dmesg t'indique que tu as des erreurs non corrigées (la dernière détectée est récente : 17/5/2017 à 20:14:33), ça peut suffire à bloquer une modification du raid. À priori c'est sur md3 (le périphérique raid, ce n'est pas nécessairement sur un disque physique).

Avant de lire la suite, assure toi que tes sauvegardes sont à jour et fonctionnelles.

Tu peux tenter un fsck (avec -n -v pour ne rien écrire) afin d'essayer d'y voir plus clair.

Mais comme tu sembles avoir ce souci depuis début janvier, une vérification de l'ensemble des volumes, non montés (donc services du nas coupés, il y a une commande pour, mais je ne m'en rappelle jamais : @gaetan.cambier ?) ne serait pas du luxe.

[Zetsubou]

Pour cela que je venais vous voir, pas moyen de garder la connexion SSH (en mode root) en utilisant :

syno_poweroff_task -d 

Je me fais éjecter en 30 secondes, et quand je me reconnecte de nouveau pour passer toujours en mode root :

umount -l /volume1

puis

vgchange -ay

e2fsck -v -n -f /dev/vg1000/lv

Le système me dit qu'il est encore utilisé, sans savoir ce qui est encore connecté au volume logique (n'ayant pas accès à la commande lsof sur mon NAS)..

La dernière commande s'exécute quand même afin de procéder à la vérification sans écriture et me trouve une erreur d'inode à un moment (que je vous fournis après un édit dans la prochaine heure).

Pour les backups, je n'en ai uniquement qu'une partie pour le moment.
Je devais lancer une procédure de sauvegarde totale de ce NAS après cette expansion et acheter les disques manquants dans les prochaines semaines (besoin encore de 10 disques de 6 To à trouver et à peupler par la suite).

Je suis déjà en train de procéder aux sauvegardes les plus vitales de ce soir (documents administratifs, photos de famille, contrats, carnet de contacts, BdD).

Pour information, j'avais changé déjà un disque 6Tb par un 8Tb il y a environ 1 mois et l'erreur ne s'était pas présentée (d'où je suis étonné que l'on me parle d'un souci depuis janvier); je n'ai eu ce souci de message d'erreur de système de fichiers que depuis la demande d'expansion il y a 12 jours.

Modifié le 17 mai 2017 par Zetsubou

[Fenrir]

Pas e2fsck mais fsck (fsck.ext4 par exemple)

Certaines appli font des points de montages interne, c'est le cas de docker, tu peux commencer par tuer les process non indispensables qui n’auraient pas été coupés par syno_poweroff_task -d

Tu peux aussi forcer l'umount avec -f, parfois ça marche

Pour lsof tu peux utiliser ça :

for proc_pid in $(find /proc -maxdepth 1 -name "[0-9]*"); do \
    ls -l ${proc_pid}/fd 2>/dev/null \
    | grep -q volume \
    && ps -q "${proc_pid#/proc/}"; \
done

ou ça :

for p in [0-9]*; do ls -l /proc/$p/fd ;done | grep volume

Ensuite il faut partir à la chasse

Par contre chez moi le syno_poweroff_task -d fonctionne correctement, le ssh ne coupe pas et l'umount fait son travail, rien que ça ce n'est pas normal.

[Zetsubou]

.J'ai réussi à passer  syno_poweroff_task -d en changeant mon timer de déconnexion dans PuTTy de 0 à 60.

Puis dans la console SSH, passer cette commande :

for p in [0-9]*; do ls -l /proc/$p/fd ;done | grep volume

pour chercher et killer les process qui seraient récalcitrants.

Je ne sais pas comment faire pour utiliser le script suivant proposé par contre.

for proc_pid in $(find /proc -maxdepth 1 -name "[0-9]*"); do \
    ls -l ${proc_pid}/fd 2>/dev/null \
    | grep -q volume \
    && ps -q "${proc_pid#/proc/}"; \
done

J'arrive à passer umount -f /volume1 pour démonter le volume.

Mais quand je veux passer fsck.ext4 -vnf /dev/vg1000/lv, il me répond : Warning! /dev/vg1000/lv is in use.

Et je ne vois pas ce qui pourrait encore bloquer après cette recherche de process à tuer.

J'ai laissé la vérification en mode lecture seule pour cette nuit, afin de trouver si des inodes posent problème.

La suite sera de trouver pourquoi le système me dit que le volume est toujours utilisé et tenter une réparation ultérieure (si possible).

Je termine de sauvegarder le plus urgent entre temps.

Merci en tout cas des réponses déjà données.

 

[Fenrir]

Pour le "script", c'est en fait une seule ligne => copier/coller dans la console

Mais comme ton volume est bien démonté, ce n'est plus utile. Il faut maintenant s'occuper de LVM

lvm pvscan
lvm vgscan
lvm lvchange -ay
lvm lvscan
fsck.ext4 -vnf /dev/vg1000/lv

edit : tu as potentiellement plusieurs LV, le lvscan devrait te l'indiquer, sinon lvdisplay

Modifié le 17 mai 2017 par Fenrir

[Zetsubou]

 lvm pvscan
  PV /dev/md2   VG vg1000   lvm2 [19.96 TiB / 0    free]
  PV /dev/md3   VG vg1000   lvm2 [20.01 TiB / 0    free]
  PV /dev/md4   VG vg1000   lvm2 [20.01 TiB / 0    free]
  PV /dev/md5   VG vg1000   lvm2 [1.82 TiB / 0    free]
  Total: 4 [61.81 TiB] / in use: 4 [61.81 TiB] / in no VG: 0 [0   ]

lvm vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "vg1000" using metadata type lvm2

 

Premier souci à cette ligne

 lvm lvchange -ay
  Please give logical volume path(s) or use --select for selection.
  Run `lvchange --help' for more information.

 

lvm lvscan
  ACTIVE            '/dev/vg1000/lv' [61.81 TiB] inherit

 

Second problème (et pourtant, j'ai bien cette fois passé les deux commandes données précédemment + tué les process qui pouvaient rester avec la commande kill - il n'y en avait qu'un au final et plus rien n’apparaissant la seconde fois après le kill).

fsck.ext4 -vnf /dev/vg1000/lv
 e2fsck 1.42.6 (21-Sep-2012)
 Warning!  /dev/vg1000/lv is in use.
 Warning: skipping journal recovery because doing a read-only filesystem check.

 

[Fenrir]

umount /dev/vg1000/lv

edit : et de tout le reste du lvm en passant

Modifié le 17 mai 2017 par Fenrir

[Zetsubou]

umount /dev/vg1000/lv
 umount: /dev/vg1000/lv: not mounted
 

J'avais pensé à revérifier avant.

[Fenrir]

Il reste quoi comme process ?

[Zetsubou]

ps -aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  24236  4360 ?        Ss   May17   0:07 /sbin/init
root         2  0.0  0.0      0     0 ?        S    May17   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    May17   0:01 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/0:0]
root         5  0.0  0.0      0     0 ?        S<   May17   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    May17   0:00 [migration/0]
root         8  0.0  0.0      0     0 ?        S    May17   0:00 [rcu_bh]
root         9  0.0  0.0      0     0 ?        S    May17   0:03 [rcu_sched]
root        10  0.0  0.0      0     0 ?        S    May17   0:00 [watchdog/0]
root        11  0.0  0.0      0     0 ?        S    May17   0:00 [watchdog/1]
root        12  0.0  0.0      0     0 ?        S    May17   0:00 [migration/1]
root        13  0.0  0.0      0     0 ?        S    May17   0:01 [ksoftirqd/1]
root        15  0.0  0.0      0     0 ?        S<   May17   0:00 [kworker/1:0H]
root        16  0.0  0.0      0     0 ?        S    May17   0:00 [watchdog/2]
root        17  0.0  0.0      0     0 ?        S    May17   0:04 [migration/2]
root        18  0.0  0.0      0     0 ?        S    May17   0:00 [ksoftirqd/2]
root        19  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/2:0]
root        20  0.0  0.0      0     0 ?        S<   May17   0:00 [kworker/2:0H]
root        21  0.0  0.0      0     0 ?        S    May17   0:00 [watchdog/3]
root        22  0.0  0.0      0     0 ?        S    May17   0:01 [migration/3]
root        23  0.0  0.0      0     0 ?        S    May17   0:00 [ksoftirqd/3]
root        25  0.0  0.0      0     0 ?        S<   May17   0:00 [kworker/3:0H]
root        26  0.0  0.0      0     0 ?        S<   May17   0:00 [khelper]
root        27  0.0  0.0      0     0 ?        S    May17   0:00 [kdevtmpfs]
root        28  0.0  0.0      0     0 ?        S<   May17   0:00 [netns]
root       185  0.0  0.0      0     0 ?        S<   May17   0:00 [writeback]
root       188  0.0  0.0      0     0 ?        S<   May17   0:00 [kintegrityd]
root       189  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root       190  0.0  0.0      0     0 ?        S<   May17   0:00 [crypto]
root       192  0.0  0.0      0     0 ?        S<   May17   0:00 [kblockd]
root       286  0.0  0.0      0     0 ?        S<   May17   0:00 [ata_sff]
root       296  0.0  0.0      0     0 ?        S<   May17   0:00 [md]
root       393  0.0  0.0      0     0 ?        S<   May17   0:00 [rpciod]
root       394  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/2:1]
root       457  0.0  0.0      0     0 ?        S    May17   0:00 [khungtaskd]
root       465  0.0  0.0      0     0 ?        S<   May17   0:00 [kswapd0]
root       472  0.0  0.0      0     0 ?        S    May17   0:00 [fsnotify_mark]
root       477  0.0  0.0      0     0 ?        S<   May17   0:00 [nfsiod]
root      2888  0.0  0.0      0     0 ?        S<   May17   0:00 [iscsi_eh]
root      2974  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_0]
root      2987  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_1]
root      2996  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_2]
root      3006  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_3]
root      3013  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_4]
root      3025  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_5]
root      3090  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_6]
root      3099  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_7]
root      3109  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_8]
root      3119  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_9]
root      3179  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_10]
root      3189  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_11]
root      3196  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_12]
root      3208  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_13]
root      4120  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_14]
root      4133  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_15]
root      4306  0.0  0.0      0     0 ?        S<   May17   0:00 [raid5wq]
root      4571  0.0  0.0      0     0 ?        S<   May17   0:00 [deferwq]
root      4725  0.0  0.0      0     0 ?        S    May17   0:00 [khubd]
root      4729  0.0  0.0      0     0 ?        S    May17   0:00 [kethubd]
root      5027  0.0  0.0      0     0 ?        S<   May17   0:00 [etxhci_wq7]
root      5105  0.0  0.0      0     0 ?        S<   May17   0:01 [kworker/2:1H]
root      5106  0.0  0.0      0     0 ?        S<   May17   0:01 [kworker/3:1H]
root      5133  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root      5134  0.0  0.0      0     0 ?        S    May17   0:03 [md0_raid1]
root      5162  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root      5163  0.0  0.0      0     0 ?        S    May17   0:00 [md1_raid1]
root      5174  0.0  0.0      0     0 ?        S<   May17   0:01 [kworker/1:1H]
root      5175  0.0  0.0      0     0 ?        S<   May17   0:01 [kworker/0:1H]
root      5302  0.0  0.0      0     0 ?        S<   May17   0:00 [ext4-group-desc]
root      5303  0.0  0.0      0     0 ?        S    May17   0:00 [jbd2/md0-8]
root      5304  0.0  0.0      0     0 ?        S<   May17   0:00 [ext4-dio-unwrit]
root      5329  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/0:2]
root      5353  0.0  0.0  17264  1460 ?        Ss   May17   0:00 /usr/bin/cgmanager --sigstop
system    5418  0.1  0.1 967488  7652 ?        Ssl  May17   0:25 /usr/bin/syslog-ng -F --worker-threads=4 -u system -g log
root      5441  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/1:5]
root      5895  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/2:5]
root      6458  0.0  0.0      0     0 ?        S    May17   0:00 [ecryptfs-kthrea]
root      6573  0.0  0.0  17840  1192 ?        Ss   May17   0:00 udevd --daemon
root      6586  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root      9705  0.0  0.0      0     0 ?        S<   May17   0:00 [bond0]
root     10965  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root     10970  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root     10971  0.0  0.0      0     0 ?        S    May17   0:00 [md5_raid1]
root     10977  0.0  0.0      0     0 ?        S    May17   0:02 [md4_raid5]
root     10980  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root     10995  0.0  0.0      0     0 ?        S    May17   0:02 [md2_raid5]
root     11150  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root     11169  0.0  0.0      0     0 ?        S    May17   0:02 [md3_raid5]
root     11576  0.0  0.0      0     0 ?        S<   May17   0:00 [kdmflush]
root     11583  0.0  0.0      0     0 ?        S<   May17   0:00 [bioset]
root     11769  0.0  0.0   6328   756 ?        S    May17   0:00 /usr/bin/inetd
root     11811  0.0  0.0  86824  1696 ?        Ss   May17   0:00 /usr/bin/sshd
root     12282  0.0  0.0      0     0 ?        S<   May17   0:00 [ext4-group-desc]
root     13153  0.0  0.0      0     0 ?        S    May17   0:00 [jbd2/dm-0-8]
root     13154  0.0  0.0      0     0 ?        S<   May17   0:00 [ext4-dio-unwrit]
root     13472  0.0  0.0      0     0 ?        S    May17   0:00 [scsi_eh_16]
root     13473  0.0  0.0      0     0 ?        S    May17   0:00 [usb-storage]
root     13571  0.0  0.0   8576   760 ttyS0    Ss+  May17   0:00 /sbin/getty 115200 console
root     15318  0.8  0.2 241756  9292 ?        SLl  May17   2:08 /usr/syno/sbin/synorelayd
root     15706  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/1:8]
root     15707  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/1:9]
root     16127  0.0  0.1 1266364 6928 ?        Ssl  May17   0:03 /var/packages/MediaServer/target/sbin/dms
root     16851  0.0  0.0      0     0 ?        S    May17   0:01 [kworker/0:5]
root     27872  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/0:3]
root     28364  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/u8:1]
root     28392  0.0  0.2 179448  8600 ?        Ss   May17   0:00 sshd: admin [priv]
root     28401  0.0  0.0 179448  2584 ?        S    May17   0:00 sshd: admin@pts/8
admin    28402  0.0  0.0  26064  2224 pts/8    Ss   May17   0:00 -sh
root     28427  0.0  0.0  44076  1760 pts/8    S    May17   0:00 sudo -i
root     28432  0.0  0.0  26108  2368 pts/8    S    May17   0:00 -ash
root     29765  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/2:3]
root     29767  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/3:0]
root     29768  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/3:1]
root     29778  0.0  0.0      0     0 ?        S    May17   0:00 [kworker/3:2]
root     30565  0.0  0.0      0     0 ?        S    00:08   0:00 [kworker/1:1]
root     30604  0.0  0.0      0     0 ?        S    00:15   0:00 [kworker/3:3]
root     30620  0.0  0.0      0     0 ?        S    00:24   0:00 [kworker/u8:2]
root     30623  0.0  0.0      0     0 ?        S    00:25   0:00 [kworker/0:1]
root     30632  0.0  0.0      0     0 ?        S    00:29   0:00 [kworker/1:0]
root     30635  0.0  0.0      0     0 ?        S    00:29   0:00 [kworker/u8:0]
root     30636  0.0  0.0      0     0 ?        S    00:29   0:00 [kworker/2:2]
root     30637  0.0  0.0      0     0 ?        S    00:29   0:00 [kworker/3:4]
root     30780  0.0  0.0  27732  1476 pts/8    R+   00:33   0:00 ps -aux
 

Modifié le 17 mai 2017 par Zetsubou

[Fenrir]

J'ai encore 2 autres pistes, mais jamais tenté (jamais eu besoin), donc il faut y aller avec des pincettes (RTFM)

• e2fsck de /dev/dm-0 ou de /dev/mapper/vg1000-lv
• et badblock (il y a quelques exemples sur le forum)

[Zetsubou]

Je vais prendre le temps de RTFM demain à la première heure, merci déjà de tous les conseils.

EDIT - 18/05/2017.

Ne voyant rien sous badblocks comme secteur realloué ou bloc défaillant sur l"intégralité des disques, ni aucune erreur dans /dev/dm-0, mais par contre il existe un inode corrompu en vérifiant /dev/mapper/vg1000-lv, je vais déjà commander les derniers disques manquants pour ma sauvegarde totale.

J'ai accès à mes données pour le moment sous DSM (et les plus critiques ont été contrôlées sur les backups dans la nuit).

En profiter pour contrôler les autres disques de sauvegarde (moins importants) déjà existants dans la même foulée, ajouter les nouveaux (après contrôles d'usage), puis recommencer mes volumes dans le DS2413+ de zéro.
Pour être plus sûr d'ici le prochain mois  - le temps de recevoir, contrôler, copier, recommencer les volumes autrement et repeupler les données dans le sens inverse.

Merci du temps accordé hier pour m'aider, mais me grattant la tête sur comment agir au mieux alors que l'on n'avançait plus mon souci, je pense qu'il me sera nécessaire de repartir proprement sur le NAS (comme beaucoup d'autres l'ont déjà fait avec les erreurs de système de fichiers).

 

Modifié le 18 mai 2017 par Zetsubou
Ajout de renseignements