6

I was able to backup a drive using the following command.

pv -EE /dev/sda > disk-image.img

This is all well and good, but now I have no way of seeing the files unless I use this command

pv disk-image.img > /dev/sda

This, of course, writes the data back to the disk which is not what I want to do. My question is what can I do to mount the .img file itself instead of just writing back to a disk?


I've tried mounting using loop but it seems to complain about an invalid NTFS.

$ mount -o loop disk-image.img
mount: disk-image.img: can't find in /etc/fstab.
$ mount -o loop disk-image.img /mnt/disk-image/
NTFS signature is missing.
Failed to mount '/dev/loop32': Invalid argument
The device '/dev/loop32' 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?
  • 1
    What does file disk-image.img tell you? – Nick ODell Sep 13 '18 at 21:41
  • 1
    disk-image.img: DOS/MBR boot sector – tisaconundrum Sep 13 '18 at 21:44
10

You backed up the whole disk including the MBR (512 bytes), and not a simple partition which you can mount, so you have to skip the MBR.

Please try with:

sudo losetup -o 512 /dev/loop0 disk-image.img
sudo mount -t ntfs-3g /dev/loop0 /mnt 

Edit: as suggested by @grawity:

sudo losetup --partscan /dev/loop0 disk-image.img
sudo mount -t ntfs-3g /dev/loop0 /mnt 
  • Splendid insight! – K7AAY Sep 13 '18 at 22:33
  • Why aren't you using losetup --partscan? How do you know that the NTFS partition will start at the 1st sector right after the MBR? Most disks have it start at sector 63 or even 2048. – user1686 Sep 14 '18 at 4:56
  • There's also the possibility of multiple partitions existing. You should use kpartx instead (which will internally handle losetup for each relevant partition). – Bob Sep 14 '18 at 6:08
  • 1
    @grawity May be an alternative solution! – Antonio Petricca Sep 14 '18 at 6:23
  • @Bob Please post an answer that can be voted on. – pipe Sep 14 '18 at 8:30
2

As others have already pointed out,

sudo losetup /dev/loop0 /path/to/disk-image.img

will set up a virtual block device that can be used to access the file, but it does not give you easy access to the partitions.

However, there is another command you can use after that to gain access to all the partitions within the disk image file, without manually calculating partition offsets:

sudo kpartx -a /dev/loop0

This will read the partition table within the disk image, and will create devices like /dev/mapper/loop0p1, /dev/mapper/loop0p2 etc. for all the partitions. You can use those to mount the partitions normally.

(If you don't remember what each partition is, you could use fdisk -l /dev/loop0 to view the partition table within the disk image; just note that many versions of fdisk will display the names of the partition devices a little oddly in this situation.)

Once you've done accessing the disk image, you can undo this set-up by unmounting the partitions you've mounted, and then using two commands:

sudo kpartx -d /dev/loop0   # remove the /dev/mapper/loop0pN partition mappings
sudo losetup -d /dev/loop0  # disconnect the image file from the loop device

The kpartx command was originally developed as a tool for multipathed devices (as used with SAN storage systems), but it is perfectly usable with disk images too.

-1

Install p7zip-full if you don't have it already, then take a look with

sudo 7z  /pathtowhereitis/whatever.img
  • 1
    Where is this image mounted? – pipe Sep 14 '18 at 8:29
  • @pipe, please consider placing this question up top, to the original poster tisaconundrum, as a comment to the original post. They may not see it down here. – K7AAY Sep 14 '18 at 17:06
  • No, I'm asking you, who wrote this answer. Using the command that you have presented as the solution to the problem of mounting the image, where can I then access the files? – pipe Sep 14 '18 at 17:19
  • Current directory – K7AAY Nov 9 '18 at 0:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.