hfsplus partition will not mount

[jcdutton]

I have a hard disk image of a Mac OS X system.
macbook1.img is the entire disk, including partition table.
hfs1.img is part of the entire disk from offset 209735680 onwards.
hfs2.img is part of the entire disk from offset 209735680 onwards and then truncated according to the length of the partition.
I tried to mount it with:
mount -t hfsplus -o ro,loop,offset=209735680 macbook1.img /n1/macbook/fs
Give this in dmesg
[320231.611112] hfs: unable to find HFS+ superblock
[320293.525940] hfs: invalid secondary volume header
[320293.525944] hfs: unable to find HFS+ superblock
[320629.619113] hfs: invalid secondary volume header

After I use dd to extract just the hfsplus partition into a single file, it still fails to mount.
Only when I truncate the image file to the exact length of the partition according to the partition table, does the mount command actually mount the image with:
mount -t hfsplus -o ro,loop hfs2.img /n1/macbook/fs

I conclude that there must be a bug in the Linux kernel hfsplus code, that wrongly locates the secondary volume header unless the image size is correct.

Output of file:
hfs1.img: Macintosh HFS Extended version 4 data last mounted by: 'HFSJ', created: Wed May 11 07:33:43 2011, last modified: Wed Oct 5 16:49:16 2011, last checked: Wed May 11 15:33:43 2011, block size: 4096, number of blocks: 14567302, free blocks: 4402186
hfs2.img: Macintosh HFS Extended version 4 data last mounted by: 'HFSJ', created: Wed May 11 08:33:43 2011, last modified: Wed Oct 5 16:49:16 2011, last checked: Wed May 11 15:33:43 2011, block size: 4096, number of blocks: 14567302, free blocks: 4402186
macbook1.img: x86 boot sector; partition 1: ID=0xee, starthead 254, startsector 1, 117210232 sectors, extended partition table (last)\011, code offset 0x0

output of parted:
Disk /n1/macbook/macbook1.img: 60011642880B
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 20480B 209735679B 209715200B fat32 EFI system partition boot
 2 209735680B 59877404671B 59667668992B hfs+ Customer

ls -l
-rw-r--r-- 1 root root 59801907200 2011-11-13 15:12 hfs1.img
-rw-r--r-- 1 root root 59667668992 2011-11-13 16:46 hfs2.img
-rw-r--r-- 1 root root 60011642880 2011-10-29 14:14 macbook1.img

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: udisks 1.0.4-1
Uname: Linux 3.1.0+ x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CustomUdevRuleFiles: plcbus.rules
Date: Sun Nov 13 18:35:30 2011
MachineType: Dell Inc. Inspiron 1521
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.1.0+ root=/dev/mapper/inspiron--hd-root ro
SourcePackage: udisks
Symptom: storage
Title: Internal hard disk partition cannot be mounted manually
UpgradeStatus: Upgraded to oneiric on 2011-10-14 (29 days ago)
dmi.bios.date: 02/03/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A06
dmi.board.name: 0GU163
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA06:bd02/03/2008:svnDellInc.:pnInspiron1521:pvr:rvnDellInc.:rn0GU163:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Inspiron 1521
dmi.sys.vendor: Dell Inc.

[Seth Forshee (sforshee)]

The HFS+ volume format specifies that the alternate volume header is to be located 1024 bytes before the end of the volume. Without the partition table information to specify the actual length of the partition, Linux must assume that the partition is the size of the device, which in the case of a loopback device would be the size of the source file. The HFS+ metadata does not seem to contain any information about the size of the volume, only the size and number of allocation blocks on the volume, which doesn't help in locating the alternate volume header because that data structure may be stored outside of the allocation blocks.

So in this case the hfsplus driver is behaving correctly according to the specification and doing the best it can do based on the available information since it does not have accurate information about the size of the volume. If you wish to mount an HFS+ volume you must supply information about where the end of the volume is, either via partition table information or by truncating the image to the actual size of the partition containing the HFS+ volume. Therefore I'm closing this bug as Invalid.

[Vedant Lath (vedant)]

Mounting HFS+ partitions from dd image files of hard disks used to work in at least Linux 2.6.32 with just loop and offset options to mount. Could we please have the old behaviour back?

[Nina Marwede (lynax)]

I see the same issue, I guess. I copied the main data partition (250 gb) from a friend's broken mac using "ddrescue /dev/sdc2 rescued.img rescued.log" and tried to mount it with "mount -o loop,ro rescued.img /mnt"

In Ubuntu 12.04 as well as 14.04 I get "invalid secondary volume header" and "unable to find HFS+ superblock".
I also tried with "losetup" manually as suggested by some forum entry but without success.
I also tried with offset and size, but it does not help because the file size of the image is equal to the original partition size.

# parted /dev/sdc unit B print
Modell: Hitachi HTS545025B9SA02 (scsi)
Festplatte /dev/sdc: 250059350016B
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Nummer Anfang Ende Größe Dateisystem Name Flags
 1 20480B 209735679B 209715200B fat32 EFI System Partition boot
 2 209735680B 249409327103B 249199591424B hfs+ Macintosh HD
 3 249409327104B 250059329535B 650002432B hfs+ Recovery HD

# file rescued.img
Macintosh HFS Extended version 4 data (mounted) last mounted by: 'HFSJ', created Thu Jun 21 12:24:20 2012, last modified: Sat May 16 20:50:35 2015, last checked: Thu Jun 21 19:24:20 2012, block size: 4096, number of blocks: 60839744, free blocks: 14124774

... but in Ubuntu 10.04 the mount works just fine!

[firewing1 (s-adam)]

While I generally hate to revive an old bugs, the HFS driver still doesn't handle CoreStorage well so I wanted to mention that it is possible to determine the appropriate value for 'sizelimit' when HFS is wrapped in a Core Storage volume: http://superuser.com/a/1088110/148367