I have a failed harddrive with around 400 GB of data, of which approximately 50 GB need to be recovered. All the data is located in a specific directory (/Fotos2018/).

The hard drive is a WD My Passport Essential WDBAAA5000ABK (500 GB, USB 2.0). It contained a FAT32 partition containing my data, as well as another partition containing some WD software.

I attempted to back up my data to a healthy hard drive, using ddrescue --no-split -r3 /dev/sdb1 defekt_wd.iso defekt_wd.log. It generated tons of errors (I don't have the output), but ended up with the output file. The log file is 1.2 MB if that gives any indication. During this operation, the hard drive sounded increasingly scratchy, and became rather hot.

I have found various methods to extract the contents, but none of them were succesful. Below are my attempts:

First, traditional mounting (however, I cannot recompile the kernel on the current machine due to the warranty terms, but if you believe this would work on a different machine, I can copy the image file)

# mount defekt_wd.img /tmp/defektdisk
mount: Could not find any loop device. Maybe this kernel does not know about the loop device? (If so, recompile or `modprobe loop'.)
# modprobe loop
FATAL: Module loop not found.

Second, using xorriso.

# xorriso -indev defekt_wd.img -ls
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.
xorriso : NOTE : Loading ISO image tree from LBA 0
libisoburn: WARNING : No ISO 9660 image at LBA 0. Creating blank image.
Drive current: -indev 'defekt_wd.img'
Media current: stdio file, overwriteable
Media status : is written , is closed
Media summary: 1 session, 228724832 data blocks,  436g data,     0 free
Volume id    : 'ISOIMAGE'
Valid ISO nodes found: 0

I have also tried to extract/list/test the archive using 7-zip, e.g.:

# 7z l defekt_wd.img 
7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)
Error: defekt_wd.img: Can not open file as archive
Errors: 1

Here's the output of file:

# file defekt_wd.img
defekt_wd.img: x86 boot sector, code offset 0x58, OEM-ID "BSD  4.4", sectors/cluster 64, Media descriptor 0xf8, heads 255, hidden sectors 2048, sectors 975394816 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 119038, reserved3 0x800000, serial number 0xac2710e2, label: "XYZ "

My current theory is that the image file contains two partitions, but I do not know how to extract the contents of just one of them. Can you offer any suggestions on what to do next?

  • 1
    Also note that this is not an ISO file (ISO files are a specific format for CDs etc.). It's an image of a partition, hopefully the one with your data, so it's a FAT 32 filesystem. Though if important parts of the file system couldn't be read and are garbage, you won't be able to do a lot with it.
    – dirkt
    Commented Oct 5, 2018 at 5:49
  • Thanks for clarifying! I changed my question from 'iso' to 'img'.
    – Kristian
    Commented Oct 10, 2018 at 18:52

3 Answers 3


Since you created an image of /dev/sdb1, you only created an image of that partition (as opposed to /dev/sdb which would have been the entire drive) As long as the first partition was the one that contained your data, that would be the right one.

As far as mounting it, try:

mount -o loop defekt_wd.img /tmp/defektdisk

To get more information about the partition table (if there is one) of the disk image use:

fdisk -l defekt_wd.img
  • Unfortunately, the mount operation resulted in the same error as in my original question, while the fdisk query did not show any partitions. Luckily, I was able to recover most of my data by copying the image data to a different physical hard drive: # ddrescue ddrescue -f defekt_wd.img /dev/sdb to_harddrive.log. See my answer to the thread for more information.
    – Kristian
    Commented Oct 10, 2018 at 18:57

My working solution was to copy the contents of ddrescue's output file to a different physical hard drive (of equal or, preferably, larger size):

# ddrescue -f defekt_wd.img /dev/sdb to_harddrive.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:   468428 MB,  errsize:       0 B,  current rate:    4653 kB/s
   ipos:   468428 MB,   errors:       0,    average rate:   34703 kB/s
   opos:   468428 MB, run time:    3.74 h,  successful read:       0 s ago

The physical harddrive with the rescued content was able to mount, and I have been lucky enough to retrieve around 80% of the important 50 GB of photos. Since the majority was JPEG-photos, I could even crop some of the photos that had been partly damaged.


I had the same problem, but with an exFAT filesystem. Since Ubuntu 20.04 doesn't have a tool in the repository to repair exFAT, I used Testdisk (testdisk /path/to/broken.img) to extract the files. Testdisk was able to still read the list of files which neither Recuva, Windows or the Windows exFAT repair could do. With this list, Testdisk was able to copy all images including filename and metadata to another volume.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .