My SATA hardrive was ejected, and is unable to be remounted due to issues
I have a Mac Pro 2012, so it's running Mountain Lion :( but it has a few partitioned drives. I have tower 1 and tower 2. Tower 2 just recently froze my computer, this has most of my videos for editing, so losing it would be quite the shame. I restarted the computer and the tower 2 icon on the left side was gone. I tried repairing it in Disk Utility, and then also in Terminal. This is the response I'm getting from my trusty ole Apple:
Last login: Tue Sep 13 18:34:11 on ttys001
DAJ-ROMMs-Mac-Pro:~ andrew$ diskutil repairDisk /dev/disk1
Repairing the partition map might erase disk1s1, proceed? (y/N) y
Started partition map repair on disk1
Checking prerequisites
Checking the partition list
Problems were encountered during repair of the partition map
Error: -69770: Partition map check failed because no slices were found
I've tried a lot of other things, like redownload the OS, and disabling spotlight through the terminal. I always end up on this response. I would really like to continue my editing, so if this rings a bell for anyone, I'd be forever grateful.
Last login: Wed Sep 14 14:03:44 on ttys000
sudo gpt -r show /dev/disk1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 1953115495
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header
gpt show: /dev/disk2: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 411614
411648 1953112064 2 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
1953523712 1423
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header
To determine what's wrong with your hard drives or volumes you first have to get an overview. The best tools to get this are diskutil and gpt – both command line tools which have to be executed in Terminal.app.
Open Terminal.app and enter:
diskutil list
To execute a command you always have to enter the Enter key.
The command above will yield something like this (depending on the number of disks in your Mac):
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 499.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk2
2: Microsoft Basic Data tower 1 1.0 TB disk2s2
The example shows the following:
- disk0 is your system drive containing an EFI partition (disk0s1), your main system volume "Macintosh HD" (disk0s2) and a recovery volume (disk0s3). All partitions sizes (0.2 GB + 499 GB + 0.7 GB) add up to the total size of the disk (500 GB)
- disk1 is a 1 TB drive only containing an EFI with a size of 200 MB and with 999.8 GB empty space
- disk2 is a 1 TB drive containing one 1 TB volume probably formatted to FAT32, ExFAT or NTFS
Now one can deduce that the missing volume tower 2 once resided on disk1.
After a reboot the disk identifiers of the second and the third disk may be exchanged! So always execute diskutil list before manipulating partition tables!
To get a closer look on disk1 use gpt:
sudo gpt -r show /dev/disk1
This will reveal:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 1953115495
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header
This means:
- The disk has a GUID partition table (GPT)
- The first partition (index = 1) is an EFI type partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B), starting at block 40 and with a size of of 409600 blocks (~209.7 MB)
- Starting at block 409640 1953115495 blocks (~1 TB) of the disk are not allocated to a partition.
You can assume that your "lost" partition (with the volume name tower 2) once resided here.
After adding a partition it has to be formatted and a file system has to be created. The file system may be (beyond others): HFS+, ExFAT or NTFS
If you know the previous file system you can continue restoring a partition. If you don't know the file system you can determine it by searching for typical file system headers.
To determine a previous HFSJ volume use:
sudo hexdump /dev/disk1 | grep "48 46 53 4a"
This will search for the string "HFSJ" on your raw disk. After getting the first results simply enter ctrlC to abort the command.
On your type of disk you should get the following results:
c805400 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
ca13e00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
ca40e00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
...
Here the important line is the first one: c805400 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff with c805400 being the offset in hex. Converted with a hex2dec service this means an offset of Byte 209736704 (dividing this by 512 Bytes/block, the result is equal to block 409642). Typically the 3rd block of an HFSJ volume contains the string "HFSJ". So you have found the beginning of an HFSJ volume: block 409640 (BlockF).
The end of an HFSJ volume can be found accordingly because the 3rd last block contains the last HFSJ occurrence:
sudo hexdump -s 930g /dev/disk1 | grep "48 46 53 4a"
The option -s means: Skip offset bytes from the beginning of the input.
With the last offset (and doing the math like above) you can determine the last block (BlockL) of the previous HFSJ volume by simply adding 2 blocks. The size of the HFSJ volume is then (BlockL-BlockF).
With all necessary data gathered you can now try to restore the lost volume tower 2 with the sudo gpt add ... command.
To add a partition entry you have to execute:
sudo gpt add -i number -b number -s number -t type diskX
with
- -i index number
- -b number of the first block
- -s size in blocks
- -t partition type
I don't know neither the first offset nor the second offset of your volume tower 2, but the command below may work and the entered sizes are probable defaults:
sudo gpt add -2 -b 409640 -s 1952443704 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk1
After adding this entry in the partition table the volume should be mounted automatically.
Check the disk and the volume with:
diskutil verifyDisk disk1
diskutil verifyVolume disk1s2
If a repair is necessary use the "prefix" repair instead of verify!
If you have any questions or can't find the string "HFSJ" please add a comment with @klanomath!