Une connaissance vient de me passer un disque dur car il n’arrive plus à y accéder.
En effet, une fois le disque dur externe branché à l’ordinateur, quelque soit le système d’exploitation (Fedora36, MacOS et Windows 10), on entends le bruit de connexion, mais le disque n’apparait pas dans le navigateur de fichiers.
Analyse de la situation
Grâce à notre Fedora, nous allons analyser si le disque dur externe est bien reconnu et pour quelle raison il ne se monte pas automatiquement.
Vérifions déjà la présence du disque au niveau USB.
$ lsusb Bus 001 Device 002: ID 8087:8001 Intel Corp. Integrated Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 004: ID 0bc2:2343 Seagate RSS LLC Portable Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 015: ID 13d3:3423 IMC Networks Bus 002 Device 002: ID 04f2:b483 Chicony Electronics Co., Ltd USB2.0 VGA UVC WebCam Bus 002 Device 018: ID 413c:301d Dell Computer Corp. Dell Universal Receiver Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On aperçoit sur le Bus USB N°3 que le DD Ext est bien présent.
Il s’agit d’un Seagate de 1 To fonctionnant en USB3 et auto-alimenté.
Vérifions sa présence dans la liste des disques.
$ sudo fdisk -l Disque /dev/sda : 223,57 GiB, 240057409536 octets, 468862128 secteurs Modèle de disque : KINGSTON SA400S3 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : CA3D62EB-7D9D-47B5-ADE9-DCBA30C1D8B6 Périphérique Début Fin Secteurs Taille Type /dev/sda1 2048 1230847 1228800 600M Système EFI /dev/sda2 1230848 3327999 2097152 1G Système de fichiers Linux /dev/sda3 3328000 468860927 465532928 222G Système de fichiers Linux Disque /dev/zram0 : 7,57 GiB, 8126464000 octets, 1984000 secteurs Unités : secteur de 1 × 4096 = 4096 octets Taille de secteur (logique / physique) : 4096 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Disque /dev/sdb : 931,51 GiB, 1000204885504 octets, 1953525167 secteurs Modèle de disque : Portable Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Nous constatons qu’il est bien présent et disponible comme /dev/sbd (dans notre cas).
Essayons de forcer son montage à la main.
// On créé un nouveau dossier temporaire dans le répertoire /media de notre système $ sudo mkdir /media/temp // On essayer de monter le disque dur dans le dossier temporaire que l'on vient de créer : $ mount /dev/sdb1 /media/temp/ mount: /media/temp: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdb, page de code ou programme auxiliaire manquant, ou autre erreur. dmesg(1) peut avoir plus d'informations après un échec de l'appel système du montage.
Il semble bien que le disque ait un ou plusieurs secteurs défectueux.
Cela peut arriver pour plein de raison. Aussi bien à force d’utilisation qu’un choc violent ou non. J’ai déjà cassé un disque dur de ce type en le mettant dans un sac à dos et avoir fait du vélo.
Pour en avoir le cœur net, vérifions grâce à l’utilitaire de disques de Fedora la qualité des partitions.
Pour ouvrir l’utilitaire, tapez « Disques » dans votre écran d’activités.
Et là, le constat est sans appel. Il va falloir reformater le disque.
Récupération des données
Avant de le formater, essayons de récupérer le maximum de chose dessus.
Pour y arriver, des logiciels existent. Nous allons utiliser PhotoRec.
Il est capable de récupérer de nombreux types de fichier dont voici la liste (en anglais)
// Commençons par installer l'utilitaire testdisk, qui embarque photorec $ sudo dnf install testdisk // Supprimons le dossier de montage de tout à l'heure, et créons un dossier de destination pour nos fichiers récupérés. $ sudo rm -rf /media/temp $ mkdir ~/recovery // Lancement de la récupération des données : $ sudo photorec
Puis, laissez vous guider par le programme, il va vous demander la source des données à récupérer, sa destination, et son type de partition.
C’est en anglais, mais c’est assez simple à comprendre.
L’opération peut durer longtemps… TRÈS longtemps… (Prévoir 3h par To)
Une fois l’opération terminée, choisissez « Quit » puis sortez du programme en ré-sélectionnant « Quit » deux fois de suite.
Vous avez désormais en vrac les fichiers récupérés dans votre dossier ~/recovery.
Ce dossier contient un ou plusieurs dossiers qui apparaissent avec un cadenas. En effet, vous avez lancé votre commande avec sudo
.
Ces dossiers et leurs fichiers appartiennent donc au super utilisateur : root
.
Pour le vérifier :
$ ls -la ~/recovery/ total 0 drwxrwxr-x. 1 user user 22 21 juil. 14:19 . drwx------. 1 user user 374 21 juil. 17:27 .. drwxr-xr-x. 1 root root 8194 21 juil. 17:23 recup_dir.1
Pour changer l’utilisateur propriétaire de ces dossiers, nous allons avoir besoin de votre nom d’utilisateur.
$ whoami <Votre nom d'utilisateur> // Approprions-nous ces fichiers $ sudo chown -R <votre nom d'utilisateur>:<votre nom d'utilisateur> ~/recovery
Voilà, vous pouvez désormais fouiller et trier vos fichiers, faire du tri, et récupérer les données qui vous sont chères.
Laisser un commentaire
Rejoindre la discussion?N’hésitez pas à contribuer !