web-dev-qa-db-fra.com

Comment lire une partition HPFS / NTFS (amorçable) sur Ubuntu (15.10)?

J'aimerais lire le contenu d'un ancien disque dur formaté en tant que partition HPFS/NTFS (bootable); Je ne suis pas sûr que la partie amorçable fasse la différence. J'ai essayé de monter le lecteur mais je ne peux pas. Comment puis-je lire ce lecteur?

Lorsque vous utilisez Sudo fdisk -l, le lecteur apparaît comme suit:

:~$ Sudo fdisk -l
Device     Boot Start       End   Sectors   Size Id Type
/dev/sdf1  *       63 488392064 488392002 232.9G  7 HPFS/NTFS/exFAT

Essayez d'utiliser mount:

:~$ Sudo mount /dev/sdf1 /mnt/ntfs1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Essayez d'utiliser ntfs-3g;

:~$ Sudo ntfs-3g /dev/sdf1 /mnt/ntfs1
NTFS signature is missing.
Failed to mount '/dev/sdf1': Invalid argument
The device '/dev/sdf1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Edit:

Essayez d'utiliser mount -t exfat:

:~$ Sudo mount -t exfat /dev/sdf1 /mnt/ntfs1
Fuse exfat 1.1.0
ERROR: exFAT file system is not found.

fsck rapport:

:~$ Sudo fsck -f /dev/sdf1
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdf1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>
mountpartitionsdriveunreadable
1
David C

Pour commencer, JAMAIS exécutez fsck sur une partition alors que vous ne le faites pas sachez que cela est la bonne chose à faire. Le problème est que fsck est un outil de réparation et qu'il est donc susceptible d'écrire des données sur le disque. Dans votre cas, vous l'avez appliqué avant même de savoir quel système de fichiers était utilisé sur le disque. Ceci est extrêmement dangereux, car l'outil de réparation pourrait avoir été confondu et avoir aggravé la situation plutôt que de mieux. Un tel résultat est improbable, mais possible. Vous n'avez probablement pas fait de mal , mais il est peu probable que vous ayez endommagé davantage le disque en utilisant fsck.

Pour savoir quel type de système de fichiers se trouve sur le disque, utilisez blkid, comme dans:

$ Sudo blkid /dev/sdb3
/dev/sdb3: UUID="493344495F520D15" TYPE="ntfs"

Bien entendu, votre sortie sera probablement différente, mais cet exemple montre un volume NTFS. Si vous n'obtenez aucune sortie, cela signifie que blkid ne peut pas identifier le système de fichiers, ce qui signifie qu'il est très gravement endommagé. S'il y a une sortie mais que TYPE= montre autre chose que ntfs, cela signifie que ce n'est pas un volume NTFS. Le résultat sera peut-être évident et vous pourrez procéder à partir de là, ou vous devrez peut-être poster avec des détails pour obtenir plus de conseils.

Avec le système de fichiers connu, vous pouvez utiliser des outils de montage spécifiques au système de fichiers et éventuellement des outils de réparation. Vous avez déjà essayé de monter avec les outils probables (NTFS et exFAT). Le code de type de la partition (0x07) était autrefois couramment utilisé pour HPFS, mais cela ne le serait probablement que si le disque avait été utilisé avec OS/2 et que vous dites qu'il était utilisé avec Windows 7.

Avant d'utiliser des outils de réparation potentiellement destructifs, il est sage de faire une sauvegarde de bas niveau, comme dans:

Sudo dd if=/dev/sdf1 of=/path/to/lots/of/space/sdf1.img

Cette commande sauvegarde /dev/sdf1 dans le fichier sdf1.img dans /path/to/lots/of/space/. Assurez-vous de disposer de suffisamment d'espace libre pour contenir la partition entière - environ 233 GiB dans votre cas. Cette sauvegarde vous permettra de récupérer si un outil de réparation aggrave la situation, comme cela se produit parfois.

Mon intuition est que le disque utilise NTFS mais qu’il est endommagé et/ou n’a pas été arrêté correctement. Si tel est le cas, vous devez d'abord le réparer avec les outils Windows. L'utilitaire Linux ntfsfix est mal nommé; il effectue uniquement les vérifications les plus minimes, puis signale que le disque requiert une attention particulière sous Windows. Il n’existe pas de support Linux pour NTFS dans fsck, vous ne devez donc pas essayer d’utiliser fsck sur un volume NTFS.

Il est également concevable qu'il se passe quelque chose de plus exotique. Par exemple, le disque a peut-être été utilisé dans une matrice RAID. Dans ce cas, vous ne pourrez peut-être rien récupérer sans les autres disques de la même matrice. (Les détails dépendent du type de RAID utilisé et d'autres détails.)

Dans le pire des cas, vous pourrez peut-être utiliser PhotoRec pour récupérer des fichiers individuels.

Un dernier point: dans vos commentaires, vous avez dit que vous avez exécuté GParted sur /dev/sdf1. Ceci est inutile - et même potentiellement dangereux. /dev/sdf1 est la partition, mais GParted est destiné à être utilisé sur le disque entier - c'est-à-dire /dev/sdf.

1
Rod Smith

Dans mon cas, ce problème a été résolu avec dislocker car j’avais un disque dur Windows 10 bitlocker verrouillé.

1
Erick Stone