Impossible de monter mon disque dur externe connecté en USB [Réglé]
Par CCM ou par la commande mount, impossible de monter mon disque dur
Système et matériels / Administration système
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
La partition est /dev/sde1, voici ce que dit la commande fsck:
Caché :
[root@localhost robert]# fsck /dev/sde1
fsck de util-linux 2.36.1
e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext4 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext4: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sde1
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>
/dev/sde1 contient un système de fichiers ntfs étiqueté « h_toshiba0 »
fsck de util-linux 2.36.1
e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext4 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext4: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sde1
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou
e2fsck -b 32768 <périphérique>
/dev/sde1 contient un système de fichiers ntfs étiqueté « h_toshiba0 »
La fin du message dit:
/dev/sde1 contient un système de fichiers ntfs étiqueté « h_toshiba0 »
[/hide]
Je suis d'accord sur l'étiquette h_toshiba0 mais pas d'accord sur le système de fichiers ntfs !!!!!!!!! c'est un disque dur que j'ai depuis longtemps et que j'avais formaté en ext4 !!! et sur lequel je faisais régulièrement des sauvegardes.
Dans le fichier /etc/fstab c'est bien de l'ext4, mais il est repéré comme étant:
# Entry for /dev/sdd1 : alors qu'il est sur /dev/sde1 je ne comprends pas
Caché :
[root@localhost robert]# cat /etc/fstab
# Entry for /dev/sda1 :
UUID=10dd64b2-a0ab-42fd-a5fc-284ffbd21bf1 / ext4 noatime,acl 1 1
# Entry for /dev/nvme0n1p2 :
UUID=DA29-0E27 /boot/EFI vfat iocharset=utf8,umask=000 0 0
# Entry for /dev/sdb1 :
LABEL=h_maxtor00 /h_maxtor00 ext4 defaults,nofail 0 0
# Entry for /dev/sdd1 :
UUID=32E0C0C5E0C09111 /h_toshiba0 ext4 defaults,nofail 0 0
# Entry for /dev/sda2 :
UUID=c728e095-e6b3-4b2e-85a9-c499c03dee89 /home ext4 noatime,acl 1 2
# Entry for /dev/nvme0n1p4 :
UUID=04822B27822B1D24 /media/windows ntfs-3g defaults,nofail,umask=000 0 0
none /proc proc defaults 0 0
# Entry for /dev/sda9 :
UUID=d6e5bef0-9628-4fc9-8350-75b8eeb9f3a9 swap swap defaults 0 0
# Entry for /dev/sda1 :
UUID=10dd64b2-a0ab-42fd-a5fc-284ffbd21bf1 / ext4 noatime,acl 1 1
# Entry for /dev/nvme0n1p2 :
UUID=DA29-0E27 /boot/EFI vfat iocharset=utf8,umask=000 0 0
# Entry for /dev/sdb1 :
LABEL=h_maxtor00 /h_maxtor00 ext4 defaults,nofail 0 0
# Entry for /dev/sdd1 :
UUID=32E0C0C5E0C09111 /h_toshiba0 ext4 defaults,nofail 0 0
# Entry for /dev/sda2 :
UUID=c728e095-e6b3-4b2e-85a9-c499c03dee89 /home ext4 noatime,acl 1 2
# Entry for /dev/nvme0n1p4 :
UUID=04822B27822B1D24 /media/windows ntfs-3g defaults,nofail,umask=000 0 0
none /proc proc defaults 0 0
# Entry for /dev/sda9 :
UUID=d6e5bef0-9628-4fc9-8350-75b8eeb9f3a9 swap swap defaults 0 0
Est-ce que quelqu'un pourrait me dire ce qu'il faudrait que je fasse pour pouvoir récupérer ce disque, si possible avec les données bien sûr ?!
pour vos réponses.
Édité par zatox Le 07/09/2021 à 15h31
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je pense qu' il faudrait regarder ce que dit un blkid (à moins que ce soit lsblk), afin de voir comment sont organisés les disques/partition. Il ne faut pas se fier au commentaires dans le fstab. En effet, les disques sont montés avec leur uid et non plus leur chemin (qui peut changer, alors que l'uuid de la partition est relativement stable (sauf si on joue avec les partitions)).
Édité par nic80 Le 07/09/2021 à 19h39
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
merci pour ta réponse nic80. Voici ce que donne la commande blkid:
Caché :
[root@localhost robert]# blkid
/dev/sdc1: LABEL="h_toshiba0" BLOCK_SIZE="512" UUID="32E0C0C5E0C09111" TYPE="ntfs" PARTUUID="3a333f9d-01"
/dev/nvme0n1p1: LABEL="RM-CM-)cupM-CM-)ration" BLOCK_SIZE="512" UUID="68E82780E8274B9E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="96ba7425-42b6-45e4-86b7-85023a787779"
/dev/nvme0n1p2: UUID="DA29-0E27" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d6a4539a-bf4a-4abc-a526-d4528a487d17"
/dev/nvme0n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="f5897f3b-6c9c-4481-8b2f-e87a4d6a2ef2"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="04822B27822B1D24" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d0e12f51-0a7d-4852-8cf1-e9da35eafdf2"
/dev/sda1: LABEL="r_mga8-sda1" UUID="10dd64b2-a0ab-42fd-a5fc-284ffbd21bf1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="927f310f-a1fb-4bd6-91d8-0e5cb1283045"
/dev/sda2: LABEL="h_mga8_sda2" UUID="c728e095-e6b3-4b2e-85a9-c499c03dee89" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="e27cb3f8-f78c-4ef1-b44b-a7c900802378"
/dev/sda3: LABEL="r_kubu_sda3" UUID="caad1a8d-7b25-4ab5-924b-b8d4073702f8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="472e4edc-e09f-4b6c-ab9c-6a164178ed38"
/dev/sda4: LABEL="android" UUID="26b8a64e-20a9-46d5-9772-fdbdc9e9c5d3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c9e212b-7299-47cc-b8f8-ab264e9fc3af"
/dev/sda5: LABEL="h_kubu_sda5" UUID="6862ca66-f08f-41af-85d1-f055f0de6966" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="128cf8ce-ccb0-4d1e-b8d5-8e66314033fc"
/dev/sda6: LABEL="r_debi_sda6" UUID="f6b34fce-d4b4-49d1-93ba-bd7c096befbe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="racine" PARTUUID="f8451729-3bcb-4c2f-a1a7-e905968e0490"
/dev/sda7: LABEL="h_debi_sda7" UUID="d069938b-4491-46e7-881e-6fcd583604cb" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="home" PARTUUID="84d2fcd0-341b-49f0-9380-610898830ad3"
/dev/sda9: UUID="d6e5bef0-9628-4fc9-8350-75b8eeb9f3a9" TYPE="swap" PARTLABEL="swap" PARTUUID="dea76301-cee3-469e-8ca8-00b8c83a14f8"
/dev/sda10: LABEL="h_mga9_sda10" UUID="19b9347d-e41d-4b73-b3b5-e4534e0b4b9b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="394432e2-fda4-4f84-b23a-20245bd2c4eb"
/dev/sda11: LABEL="r_mga9_sda11" UUID="a3c64ef4-e1b6-466c-8a54-8741a455b97e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0e26cd30-8ea0-42b0-b055-1a6a002ccad6"
/dev/sdc1: LABEL="h_toshiba0" BLOCK_SIZE="512" UUID="32E0C0C5E0C09111" TYPE="ntfs" PARTUUID="3a333f9d-01"
/dev/nvme0n1p1: LABEL="RM-CM-)cupM-CM-)ration" BLOCK_SIZE="512" UUID="68E82780E8274B9E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="96ba7425-42b6-45e4-86b7-85023a787779"
/dev/nvme0n1p2: UUID="DA29-0E27" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d6a4539a-bf4a-4abc-a526-d4528a487d17"
/dev/nvme0n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="f5897f3b-6c9c-4481-8b2f-e87a4d6a2ef2"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="04822B27822B1D24" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d0e12f51-0a7d-4852-8cf1-e9da35eafdf2"
/dev/sda1: LABEL="r_mga8-sda1" UUID="10dd64b2-a0ab-42fd-a5fc-284ffbd21bf1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="927f310f-a1fb-4bd6-91d8-0e5cb1283045"
/dev/sda2: LABEL="h_mga8_sda2" UUID="c728e095-e6b3-4b2e-85a9-c499c03dee89" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="e27cb3f8-f78c-4ef1-b44b-a7c900802378"
/dev/sda3: LABEL="r_kubu_sda3" UUID="caad1a8d-7b25-4ab5-924b-b8d4073702f8" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="472e4edc-e09f-4b6c-ab9c-6a164178ed38"
/dev/sda4: LABEL="android" UUID="26b8a64e-20a9-46d5-9772-fdbdc9e9c5d3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3c9e212b-7299-47cc-b8f8-ab264e9fc3af"
/dev/sda5: LABEL="h_kubu_sda5" UUID="6862ca66-f08f-41af-85d1-f055f0de6966" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="128cf8ce-ccb0-4d1e-b8d5-8e66314033fc"
/dev/sda6: LABEL="r_debi_sda6" UUID="f6b34fce-d4b4-49d1-93ba-bd7c096befbe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="racine" PARTUUID="f8451729-3bcb-4c2f-a1a7-e905968e0490"
/dev/sda7: LABEL="h_debi_sda7" UUID="d069938b-4491-46e7-881e-6fcd583604cb" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="home" PARTUUID="84d2fcd0-341b-49f0-9380-610898830ad3"
/dev/sda9: UUID="d6e5bef0-9628-4fc9-8350-75b8eeb9f3a9" TYPE="swap" PARTLABEL="swap" PARTUUID="dea76301-cee3-469e-8ca8-00b8c83a14f8"
/dev/sda10: LABEL="h_mga9_sda10" UUID="19b9347d-e41d-4b73-b3b5-e4534e0b4b9b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="394432e2-fda4-4f84-b23a-20245bd2c4eb"
/dev/sda11: LABEL="r_mga9_sda11" UUID="a3c64ef4-e1b6-466c-8a54-8741a455b97e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0e26cd30-8ea0-42b0-b055-1a6a002ccad6"
On trouve bien le disque /dev/sdc1/ mais je ne comprends pas qu'il soit en TYPE="ntfs" ... mystère ... je formate toujours en ext4, c'est un disque de sauvegarde je ne comprends pas par quel artifice il a pu passer en ntfs !!!!!
et lsblk:
Caché :
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 116,7G 0 part /
├─sda2 8:2 0 444G 0 part /home
├─sda3 8:3 0 78,1G 0 part
├─sda4 8:4 0 29,3G 0 part
├─sda5 8:5 0 20,5G 0 part
├─sda6 8:6 0 39,1G 0 part
├─sda7 8:7 0 59,6G 0 part
├─sda9 8:9 0 3,7G 0 part [SWAP]
├─sda10 8:10 0 62,4G 0 part
└─sda11 8:11 0 78,1G 0 part
sdc 8:32 0 931,5G 0 disk
└─sdc1 8:33 0 931,5G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 119,2G 0 disk
├─nvme0n1p1 259:1 0 450M 0 part
├─nvme0n1p2 259:2 0 100M 0 part /boot/EFI
├─nvme0n1p3 259:3 0 16M 0 part
└─nvme0n1p4 259:4 0 118,7G 0 part /media/windows
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 116,7G 0 part /
├─sda2 8:2 0 444G 0 part /home
├─sda3 8:3 0 78,1G 0 part
├─sda4 8:4 0 29,3G 0 part
├─sda5 8:5 0 20,5G 0 part
├─sda6 8:6 0 39,1G 0 part
├─sda7 8:7 0 59,6G 0 part
├─sda9 8:9 0 3,7G 0 part [SWAP]
├─sda10 8:10 0 62,4G 0 part
└─sda11 8:11 0 78,1G 0 part
sdc 8:32 0 931,5G 0 disk
└─sdc1 8:33 0 931,5G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 119,2G 0 disk
├─nvme0n1p1 259:1 0 450M 0 part
├─nvme0n1p2 259:2 0 100M 0 part /boot/EFI
├─nvme0n1p3 259:3 0 16M 0 part
└─nvme0n1p4 259:4 0 118,7G 0 part /media/windows
pour vos réponses.Édité par zatox Le 07/09/2021 à 23h07
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Mageia ne pouvant plus monter mon disque dur externe pour une raison inconnue, également pour une raison inconnue ce disque se trouve actuellement en NTFS !!! alors qu'il était formaté depuis longtemps en ext4, je suis passé sous windows pour voir ce que ça donnait. Et là ça donnait bien puisque le disque était visible, je pouvais faire des manips dessus, création de dossiers fichiers ect ...
Je suis revenu sous Mageia, et là, comme par enchantement ... le disque est apparu comme monté avec tous les dossiers et fichiers qui étaient dessus avant l'incident !!!
J'ai plusieurs disques durs externes tous toujours formatés en ext4 et maintenant celui qui posait problème et qui est formaté, indépendanmment de ma volonté, en NTFS !! personnellement ça ne me gêne pas dans la mesure où je peux travailler dessus, mais j'espère que ça ne cache pas des problèmes futurs ...
De toutes façons, d'après ce que j'avais pu voir sur internet, il semble qu'il ne soit pas possible de formater un disque qui est en NTFS, le formater en ext4 sans perdre les données.
Donc pour une fois windaube est venu à mon secours, désolé de dire ça comme ça mais c'est ainsi.
Si quelqu'un a une idée sur ce qui a pu se passer, elle sera la bienvenue.
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Mon idée est que, quoique tu en dises et certainement à l'insu de ton plein gré, ce disque a été formaté initialement en NTFS... Peut être était son formatage initial.
Une opération de changement de formatage, si elle conservait les données, ne serait de toute façon pas anodine et ne pourrait se faire dans ton dos.
Guygoye Membre non connecté
-
- Voir le profil du membre Guygoye
- Inscrit le : 25/10/2018
- Groupes :
-
Modérateur
-
Forgeron
Du coup, ton problème ressemble à un mauvais démontage de ton disque. Il m'est déjà arrivé de bloquer un disque mal démonté et bien souvent c'était en passant de Windows à Linux.
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Papoteur :
Mon idée est que, quoique tu en dises et certainement à l'insu de ton plein gré, ce disque a été formaté initialement en NTFS... Peut être était son formatage initial.
Une opération de changement de formatage, si elle conservait les données, ne serait de toute façon pas anodine et ne pourrait se faire dans ton dos.
Une opération de changement de formatage, si elle conservait les données, ne serait de toute façon pas anodine et ne pourrait se faire dans ton dos.
Bonjour Papoteur, et merci pour ta réponse.
Il est possible que tu aies raison, car moi non plus je ne comprends pas comment d'un disque formaté en ext4 il pourrait passer sans autre forme de procès en ntfs et en gardant les données
Donc je vais considérer que tu as raison, bien que j'ai 3 disques durs externes dont 2 sont formatés en ext4 et 1 en ntfs !!!!
Cependant, une chose est sûre c'est que jusqu'au 6 septembre 2021 j'accédais à ce disque sans problème. A partir du 6 je ne pouvais plus monter ce disque sur Mageia ! il a suffit que j'aille lire ce disque sous windows et euréka, après avoir vu windows j'ai pu le monter sur Mageia !! euh ... d'ailleurs je n'ai même pas eu à le remonter, il était automatiquement monté au redémarrage.
Bon je ne vais pas épiloguer plus longtemps et je vais dire que ton idée, Papoteur, me convient très bien concernant le flip-flop ext4-ntfs
je ne pense pas que ce soit possible.J'aurai juste aimé pouvoir régler le problème de montage sur linux et non pas de faire lire le disque à windows ... pour ensuite m'apercevoir que je le voyais sur linux !!
Guygoye :
Du coup, ton problème ressemble à un mauvais démontage de ton disque. Il m'est déjà arrivé de bloquer un disque mal démonté et bien souvent c'était en passant de Windows à Linux.
Bonjour Guygoye, et merci pour ta réponse.
Il est effectivement possible que le problème soit dû à un mauvais démontage du disque, peut-être suite à une copie ou autre opération portant sur ce disque. Par contre pour moi ce n'est pas de passant de windows à linux. Windows je ne l'utilise jamais, il est sur mon PC car quand je l'ai acheté je ne pouvais pas faire autrement que d'avoir windows. Ce qui a pu se produite effectivement c'est un mauvais démontage sur linux, et comme je dis plus haut à Papoteur, j'aurai préféré pouvoir régler ce problème soudain de montage depuis Linux.
Édité par zatox Le 10/09/2021 à 11h34
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
On préfère laisser le NTFS géré par les outils de Microsoft.
Il y aurait pu y avoir
ntfsfix /dev/sdXn
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
Papoteur :
On préfère laisser le NTFS géré par les outils de Microsoft.
Il y aurait pu y avoir
ntfsfix /dev/sdXn
Il y aurait pu y avoir
ntfsfix /dev/sdXn
Ok merci Papoteur, je vais mettre en résolu.
à toutes et à tous.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie