I cloned a disk containing an HFS+ volume to a larger disk using the command line dd utility. Now I want to grow the HFS+ volume to fill the new disk. There's an EFI partition before the HFS+ volume in the partition table but nothing after it.

When I attempt to resize the HFS+ volume in Disk Utility, it acts like everything works, but completes in about 4 seconds without making any changes to the partition table. Trying from the command line using sudo diskutil resizeVolume /dev/disk3s2 0 gives 0 does not appear to be a valid disk size. If I use a size of 2T instead, I get the error Error: -5341: MediaKit reports partition (map) too small.

How can I resize this partition? I'd prefer not to have to copy the data to the new drive all over again.

3 Answers 3


This is really terrifying that the only answer suggest to overwrite your gpt table.

The correct and safest solution, with explanation, is from this comment.

  1. download GParted-Live CD from http://www.gparted.org/download.php
  2. boot from this CD
  3. accept the suggestion to enable the full disk
  4. reboot from mac OSX
  5. try again – now you can resize it!


The only problem is the disk header which exists twice: at the beginning and at the end of of the disk. Somehow Mac OSX shows the real disk size, but is not capable to change the GPT size header and to relocate the second “header” to the real disk end.

  • 1
    this doesnt work - gparted sees my main hfs partition as "unknown"
    – redbeam_
    Feb 3, 2018 at 16:17
  • 1
    The terminal utility gdisk offers an operation called "relocate backup data structures to end of disk" through its expert options, which does exactly that without a cryptic message, and it can run on macOS or the macOS recovery environment.
    – Bachsau
    Jan 15, 2020 at 18:55

Following instructions from this helpful article, I wiped and rebuilt the partition table (GPT). Basic commands used:

sudo diskutil unmount /dev/disk3
sudo gpt show /dev/disk3 > ~/tmp/disk3-gpt
sudo gpt destroy /dev/disk3
sudo gpt create -f /dev/disk3    # -f for MBR compatibility
sudo gpt add -b ${start} -s ${size} -t ${type_guid} /dev/disk3
# repeat above command for each partition to be re-added

Afterwards, I used the Disk Utility application to resize the HFS+ volume. It worked!

OSX may remount partitions immediately after they are re-added; in this case, you will need to unmount them again before continuing to re-add more partitions.

If the command line is not your thing, well, then you probably didn't clone your drive with dd in the first place.

  • Worked for me. I rebuilt the GPT table and now I can resize the main hfs partition. You have to use the gpt destroy command instead of gpt delete though (ref).
    – redbeam_
    Feb 3, 2018 at 16:19
  • Destroying the GPT just to relocate the backup table is asking for trouble.
    – Bachsau
    Jan 15, 2020 at 18:56

I add another answer, because

  • I think there is a safer way repairing the GPT than @intuited did
  • it works from standard Linux except actual resizing
  • it cares for SSD trim as far as it's possible with HFS+.

So, you need to do this only if you want to make sure most of the actually empty blocks are marked as empty on your SSD for performance (and wear?) reasons.

If you are not working with an SSD you may skip most of this and only do step 2 for the whole disk (just omit count=220), then step 3 and finally 7.

Now let's start. My source is SDI, target SDH. Be sure to double check this for every command, as mistakes may be fatal.

  1. secure erase the target SSD, as described here https://www.thomas-krenn.com/de/wiki/SSD_Secure_Erase because HFS+ cannot trim the SSD.

  2. clone partition table and EFI partition using (let's say 10% more than the size of your EFI partition)

    sudo dd if=/dev/sdi of=/dev/sdh bs=1M count=220
  3. repair the GPT partition table using gdisk (in my case the source disk is larger because it's a temporary clone of the original. The original was smaller, though. So your error messages will be a little different)

    $ sudo gdisk /dev/sdh
    GPT fdisk (gdisk) version 1.0.5
    Main header: OK
    Backup header: ERROR
    Main partition table: OK
    Backup partition table: ERROR
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: damaged
    Command (? for help): ?
    x       extra functionality (experts only)
    Command (? for help): x
    Expert command (? for help): ?
    r       recovery and transformation options (experts only)
    Expert command (? for help): r
    Recovery/transformation command (? for help): ?
    b       use backup GPT header (rebuilding main)
    c       load backup partition table from disk (rebuilding main)
    d       use main GPT header (rebuilding backup)
    e       load main partition table from disk (rebuilding backup)
    Recovery/transformation command (? for help): d
    Recovery/transformation command (? for help): w
    Caution! Secondary header was placed beyond the disk's limits! Moving the
    header, but other problems may occur!
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/sdh.
    The operation has completed successfully.
  4. check the partition table

    $ sudo gdisk /dev/sdh
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with protective MBR; using GPT.
  5. issue sudo partprobe so the system re-reads the partition table (I think GPT did already, but better be safe)

  6. copy partition content using

    sudo partclone.hfsplus -b -s /dev/sdi2 -o /dev/sdh2 -L /tmp/partclone.log
  7. resize using Disk Utility as described in the other answers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .