How to mount possibly corrupt .img file

You can mount a potentially corrupt .img file by first repairing the filesystem integrity using fsck with the -f (force) flag, which ignores clean state checks and attempts to fix logical errors. If the image is severely damaged or lacks a valid superblock, you may need to use specialized recovery tools like photorec or testdisk to extract data before attempting a standard mount operation.

Assessing the Image Integrity

Before attempting any mounting operations, it is crucial to understand the nature of the corruption. An .img file is typically a raw disk image that contains the exact binary content of a storage medium, including partition tables, boot sectors, and filesystem metadata. Corruption can stem from incomplete writes, hardware failures during creation, or bit rot over time. Start by checking the file size against expected values. A truncated image will often fail to mount because the filesystem expects more data than is present. Use the ls -lh command to verify the size. Additionally, check for obvious signs of corruption by running file your_image.img. This command identifies the file type; if it returns "data" instead of a specific filesystem like ext4, NTFS, or FAT32, the header may be damaged. If you suspect the corruption is minor, such as a dirty shutdown flag, proceeding directly to repair is efficient. However, if the file structure appears completely garbled, creating a backup copy using dd is essential. Never work on the original source file. Use the command dd if=source.img of=backup.img bs=4M conv=noerror,sync to create a resilient backup that skips unreadable sectors rather than halting the process.

Repairing Filesystem Errors with fsck

The most common tool for repairing mounted or unmounted filesystems in Linux environments is fsck (File System Consistency Check). When dealing with an image file, you cannot mount it directly if the filesystem reports errors, as many kernels refuse to mount read-write on a dirty filesystem. Instead, you must run fsck on the image file itself. First, identify the filesystem type within the image. You can do this by examining the offset of the filesystem start using fdisk -l your_image.img. Look for the "Start" sector of the primary partition. Once identified, you can run fsck targeting that specific loop device or partition offset. For simplicity, if the image contains a single filesystem spanning the entire file, you can target the file directly. Use the following command to force a repair:

sudo fsck -f -y /path/to/your_image.img

The -f flag forces checking even if the filesystem appears clean. The -y flag automatically answers "yes" to all repair prompts, which is useful for scripting but requires caution. Review the output carefully. If fsck reports that it fixed inode counts, block counts, or directory structures, these changes are written back to the image file. After running the repair, attempt to mount the image again. If fsck fails or reports irreparable errors, the corruption may be at the block level rather than the filesystem logic level. In such cases, try mounting with the ro (read-only) option to prevent further damage while you extract critical files. Use mount -o ro,loop /path/to/your_image.img /mnt/point. Read-only mounting allows access to recoverable data without triggering write-back mechanisms that might exacerbate the issue.

Handling Severe Corruption and Data Recovery

When standard filesystem repair tools fail, the image may have suffered structural damage that prevents recognition of the filesystem boundaries. This often happens when the partition table or the superblock is overwritten or corrupted. In these scenarios, traditional mounting methods will return errors like "wrong fs type, bad superblock, or missing codepage." For severe cases, consider using testdisk, a powerful partition recovery tool. It can scan the image for lost partitions and rebuild the partition table. Run testdisk your_image.img, select "Analyse," and look for existing partitions. If found, you can write the new partition table and then attempt to mount the recovered partition. Another robust approach is using photorec, part of the TestDisk suite. Unlike testdisk, which recovers partition tables, photorec ignores the filesystem structure and searches for deleted or intact file signatures on the disk. This method bypasses corrupted headers entirely. While it does not preserve filenames or directory structures, it is highly effective for retrieving documents, images, and videos from severely damaged images. Run photorec your_image.img and follow the interactive menu to select the file types you wish to recover. Specify an output directory on a different healthy drive to avoid overwriting data. This process is read-only and safe for the source image.

Making the Mounted Image Accessible

Once the image is repaired or recovered, making it accessible for troubleshooting involves proper mounting techniques. Always create a dedicated mount point directory. Use mkdir /mnt/recovery to establish a clean environment. Then, mount the image using the loop device option.

sudo mount -o loop,ro /path/to/repaired_image.img /mnt/recovery

The loop option tells the kernel to treat the file as a block device. The ro option ensures that no accidental writes occur during your inspection. If you successfully mounted the image, navigate to /mnt/recovery and list the contents. Verify the integrity of key files by comparing checksums if available. If the image contains multiple partitions, you may need to specify the partition number. For example, if the image has two partitions, you might mount the second one using losetup --partscan --show your_image.img to create loop devices like /dev/loop0p1 and /dev/loop0p2, then mount /dev/loop0p2 specifically. This granularity helps isolate issues to specific volumes within the larger image.

Frequently Asked Questions

Can I mount a corrupt image without repairing it first?

Yes, you can attempt to mount the image in read-only mode using the -o ro,loop options. This prevents the system from trying to sync dirty buffers to disk, which could worsen corruption. However, if the filesystem metadata is too damaged, the kernel may still refuse to mount it, returning an error about an unknown or bad filesystem.

What should I do if fsck says the superblock is corrupted?

If the primary superblock is damaged, fsck might suggest using a backup superblock. You can find backup superblocks using dumpe2fs -h image.img | grep superblock. Then, run fsck -b [backup_superblock_number] image.img to restore the filesystem structure from the backup. This is a common fix for ext2/ext3/ext4 filesystems.

Is it safe to use photorec on a live system?

Yes, photorec is designed to be run on the host system and reads directly from the image file or disk device. It does not modify the source media unless you explicitly instruct it to write recovered files back to the same drive, which you should always avoid. Ensure you save recovered data to a separate, healthy storage device.

Why does my mount command fail with "Invalid argument"?

This error often occurs when trying to mount a sparse image or one with unsupported features on an older kernel. Ensure you are using a recent version of the mount utility. Additionally, check if the image format is actually supported by your kernel; some proprietary or rare filesystems require additional kernel modules or third-party drivers to be mounted via loop devices.

How can I check if the corruption is due to truncation?

Compare the actual file size of the .img file with the theoretical size calculated from the partition table. If the file ends abruptly before the last sector indicated by fdisk or sfdisk, the image is truncated. Truncated images cannot be fully repaired by fsck; you must reconstruct the missing data or accept that the final portion of the disk is unrecoverable.