Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The hard drive on my MacBook Pro has two partitions. One with the OS and the other with data.

Yesterday, from a USB boot drive, I performed a clean installation of Mountain Lion to the OS drive. I created the USB boot installer from InstallESD.dmg that I received from purchasing the OS from the Mac App Store.

Now I can't see or mount my data partition. I'm wondering if there's a problem with the MBR. In Disk Utility it shows up as "disk0s4", but it's greyed out.

Any ideas on how I can mount the data partition so I can get my data off it?

For diskutil list disk0 the result is:

   #:                                 TYPE NAME         SIZE       IDENTIFIER
   0:                GUID_partition_scheme             *500.1 GB   disk0
   1:                                  EFI              209.7 MB   disk0s1
   2:                            Apple_HFS MacBook OS    99.5 GB   disk0s2
   3:                           Apple_Boot Recovery HD  650.0 MB   disk0s3
   4: 46860E2C-2310-4F96-99F6-616D0B4CB55D              399.6 GB   disk0s4

Here's the result of diskutil info /dev/disk0s4

Device Identifier:        disk0s4
Device Node:              /dev/disk0s4
Part of Whole:            disk0
Device / Media Name:      MacBook Data

Volume Name:              Not applicable (no file system)

Mounted:                  Not applicable (no file system)

File System:              None

Partition Type:           46860E2C-2310-4F96-99F6-616D0B4CB55D
OS Can Be Installed:      No
Media Type:               Generic
Protocol:                 SATA
SMART Status:             Verified

Total Size:               399.6 GB (399629668352 Bytes) (exactly 780526696 512-Byte-Blocks)
Volume Free Space:        Not applicable (no file system)
Device Block Size:        512 Bytes

Read-Only Media:          No
Read-Only Volume:         Not applicable (no file system)
Ejectable:                No

Whole:                    No
Internal:                 Yes
Solid State:              No
share|improve this question
/dev/disk0 0: GUID_partition_scheme *500.1 GB disk0 1: EFI 209.7 MB disk0s1 2: Apple_HFS MacBook OS 99.5 GB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3 4: 46860E2C-2310-4F96-99F6-616D0B4CB55D 399.6 GB disk0s4 – Todd K. Aug 2 '12 at 17:03
I installed from a USB boot disk I created. Upgraded on several other machines with no issues. I'm trying a demo of ProSoftEng's Data Rescue 3 now. I just want to get my data! – Todd K. Aug 2 '12 at 19:09
Did you use InstallESD.dmg alone (without Install OS X Mountain to produce that USB boot disk? Please edit the opening question to include the information … and for the moment, set aside thoughts of other machines; let's focus on this one – thanks. – Graham Perrin Aug 2 '12 at 19:18
For at least one build of Lion: Install.ESD was not applicable to all Lion-capable Macs. Wonder whether the same is true for Mountain Lion. – Graham Perrin Aug 3 '12 at 7:57
The answer from @DeepanshuUtkarsh helped me to find other questions that may be of interest: Best resources on data recovery from corrupted OS X HFS+ partitions (2010-11-24), Recover partitions or data after partition map becomes corrupted (HFS+) (2011-05-07) and How to recover a deleted/replaced HFS+ partition from external drive? (2012-06-05). – Graham Perrin Aug 6 '12 at 18:25

Mounting the volume

Disk Utility verification and possible repair of the partition map

If you have not already done so, use Disk Utility 13 (426) in OS X 10.8 to select then verify:

  • not the greyed-out partition
  • instead, the physical disk that contains the partition.

If verification reveals a problem with the partition map, then consider allowing Disk Utility to attempt a repair.

Proceeding without Disk Utility

Credit to Caesium's answer for finding the asr suggestion.

Here with a disposable JHFS+ volume, an example of adjustments working as expected. Note the file system checks:

macbookpro08-centrim:~ gjp22$ diskutil unmount /dev/disk12s1
Volume sandpit on disk12s1 unmounted
macbookpro08-centrim:~ gjp22$ sudo asr adjust --target /dev/disk12s1 --settype "Apple_UFS"
Fsck /dev/disk12s1 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully
macbookpro08-centrim:~ gjp22$ diskutil list disk12
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *256.9 MB   disk12
   1:                  Apple_UFS sandpit                 256.9 MB   disk12s1
macbookpro08-centrim:~ gjp22$ diskutil mount readOnly /dev/disk12s1
Volume on disk12s1 failed to mount
macbookpro08-centrim:~ gjp22$ sudo asr adjust --target /dev/disk12s1 --settype "Apple_HFS"
Fsck /dev/disk12s1 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully
macbookpro08-centrim:~ gjp22$ diskutil mount readOnly /dev/disk12s1
Volume sandpit on /dev/disk12s1 mounted
macbookpro08-centrim:~ gjp22$ 

If the type of your own /dev/disk0s4 can not be safely adjusted or (re)set to Apple_HFS then:

  • the operating system may no longer work with the HFS Plus file system (or remnants thereof) that occupies, or occupied, the affected area of the physical disk; and
  • you might doubt the integrity of the partition (start and end blocks, and so on).

Relevant lines from /private/var/log/install.log should reveal what, if anything, happened to disk0s4 before, during or after installation of the OS to disk0s2. This logged information may become critical to regaining easy access to the data.

Getting the data without mounting the volume

Good luck with your use of Data Rescue 3 – I have the app, but have never attempted to recover from any area of a disk where the partition type has been affected in this way.


Device/media name

This is sometimes, not always, a match for the volume name. Here for example:

macbookpro08-centrim:~ gjp22$ diskutil info disk0s2 | grep Name:
   Device / Media Name:      swap
   Volume Name:              swap
macbookpro08-centrim:~ gjp22$ diskutil info disk0s4 | grep Name:
   Device / Media Name:      Untitled
   Volume Name:              spare

For Todd K., presence of the device/media name –

MacBook Data

– raises hope that start and end blocks etc. are good, that only the type of the partition is wrong.

No Recovery System 10.8 for OS X 10.8

Recovery HD implies Recovery OS 10.7.x.

In any case such as this, an installation that is incomplete (that is without the expected upgrade to the Apple_Boot slice) signals that a nonstandard method of installation – with only part of Apple's installer app – may have been used.

Side note

GUID Partition Table, as it's described in Disk Utility, is the norm for this type of modern installation of OS X – not Master Boot Record.

share|improve this answer

Interestingly, two Google results if you search for that GUID, 46860E2C-2310-4F96-99F6-616D0B4CB55D.

One of them refers to a command that might set the partition type back to Apple_HFS (assuming it was that in the first place?), so might be worth a go?

sudo asr adjust --target /dev/disk0s4 --settype "Apple_HFS"


[Edit: seems like my asr on Mountain Lion doesn't have an adjust argument to asr] :(

share|improve this answer
I tried the sudo command and received the following message: Volume adjustment failed: Unknown error: -123 – Todd K. Aug 2 '12 at 20:14
The adjust verb of asr seems to be undocumented by Apple, but understood elsewhere, for example justindelliott/PartitionAndRestoreLionRecoveryHD. I can find no information about the unknown error code. – Graham Perrin Aug 2 '12 at 21:05

Download testdisk and refer to the embedded instructions. It is a very powerful piece of software, so use it carefully. It will rebuild disk0s4’s partition and then the filesystem. All your files will be back as it is. I recommend this because it is very user friendly and I saved 2000 bucks on data recovery because of testdisk.

share|improve this answer
I'm trying it now. It's the first tool that's even recognized the missing partition. I'll post the outcome. Thanks! – Todd K. Aug 3 '12 at 14:39
Is it normal for the "quick search" to take a long time? – Todd K. Aug 3 '12 at 14:49
No. You probably entered deep search. Did you specify GPT/EFI as the partition table type? You should have written the partition table when it recognised the missing partition. Check the Readme file. – duci9y Aug 3 '12 at 15:39
The readme.txt file just refers me to the web resources. After running the sudo option, I see the drive listed four times as: /dev/disk0, /dev/disk3, /dev/rdisk0 and /dev/rdisk3. I can see the "MacBook Data" partition on /dev/rdisk0. It tells me that write access for this media is not avaiable. Do I need to boot in a recovery mode and not in the OS? – Todd K. Aug 3 '12 at 17:45
Oh yeah I forgot that! You have to boot from the Recovery HD or other recovery media. – duci9y Aug 3 '12 at 18:20

I had the same issue, I had to rsync data out of the partition, delete and recreate and re-move data back again..

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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