Partition on HFS+ external drive: "Invalid number of allocation blocks", file system check exit code 8. Unable to repair, even in recovery mode

Question

As the title says, I'm getting the error "Invalid number of allocation blocks" on a particular HFS+ partition of an external drive. I am unable to repair, even in recovery mode.

Log results when I run Repair on drive:

Checking prerequisites
Checking the partition list
Checking the partition map size
Checking for an EFI system partition
Checking the EFI system partition’s size
Checking the EFI system partition’s file system
Checking the EFI system partition’s folder content
Checking all HFS data partition loader spaces
Volume Time Machine on disk1s4 has 1,048,576 bytes of trailing loader space and it needs 134,217,728 bytes
Problems were found with the partition map which might prevent booting
Operation successful.

Log results when I run Repair on the troubled partition:

Repairing file system.
Checking Journaled HFS Plus volume.
Invalid number of allocation blocks
The volume   could not be verified completely.
File system check exit code is 8.
Updating boot support partitions for the volume as required.
File system verify or repair failed.
Operation failed…

The weird thing is that the other partitions on the drive don't have any problems.

I was looking into some solutions and found this guide but I not sure if that tutorial is applicable to my situation. I downloaded wxHexEditor and can use it if need be.

Edit: Results of sudo gpt -r show disk1

gpt show: disk1: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640   667388392      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   667798032   508383336         
  1176181368   292707720      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1468889088        2048         
  1468891136   146485248      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1615376384   171884544         
  1787260928   166260736      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1953521664        3471         
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

Screen cap of the partition map. The first section is just a general OS X file storage section. Then a time machine partition, then two bootcamp partitions... (long story on why there's two but I don't use either. They were just backups in case the transfer to the new drive didn't work (I could delete them if I needed to.)

The weird thing is that this is reporting that the first partition is only 342 GB. In reality it is around 690 GB [690=1000-(85+75+150)]. If you look the drive is 1 TB in total and the partition does take up a little over half the drive (the pie chart is accurate but the number is not). I just noticed this. I think it's a new problem since I've been trying to work on this. The 342 number is either how much free space there is or how much is used. I remember that is was about half full. In Paragon I was messing around becuse bootcamp creates a MBR scheme and then GUID within that (if I understand correctly) so that the MBR/NTFS can coexist with the GUID/HFS+ on the same drive. I didn't mean to mess it up though...)

Output of df:

Filesystem                        512-blocks      Used Available Capacity iused      ifree %iused  Mounted on
/dev/disk0s2                       975425848 398002368 576911480    41% 1868271 4293099008    0%   /
devfs                                    385       385         0   100%     666          0  100%   /dev
map -hosts                                 0         0         0   100%       0          0  100%   /net
map auto_home                              0         0         0   100%       0          0  100%   /home
localhost:/LBoQ0M7--2Q2sv3sqi-Zd2  975425848 975425848         0   100%       0          0  100%   /Volumes/MobileBackups
/dev/disk1s3                       146485240 140371096   6114144    96%  217662    3074418    7%   /Volumes/Windows Bootcamp New
/dev/disk1s5                       166260728 136275960  29984768    82%  176094   15051298    1%   /Volumes/Windows Bootcamp Original (Old)
/dev/disk1s4                       292707720 184526648 108181072    64%  859054 4294108225    0%   /Volumes/Time Machine
/dev/disk1s2                      1175509584 481193080 694316504    41% 1098583 4293868696    0%   /Volumes/Macintosh HD

IMO the linked guide probably shouldn't apply here. Please add the output of sudo gpt -r show disk1 entered in Terminal. What's the history of the disk? Did you change the partition map or encrypt the volume? — klanomath, Nov 23 '16 at 00:09
Added the output. The history is that I used a program called "paragon hard disk manager" to help me copy a bootcamp partition from off the external drive in question now to a different drive. I also used it to repartition to shrink the NTFS drive down and remove unused space in the partition. @klanomath — Jon B, Nov 23 '16 at 00:24
Oh, I see it: that's a complete mess of a GUID/MBR partition table. I remember the app (Paragon...) - it was available in an 8-app bundle (~$16) and i wanted to buy in September to test it, but I was too late. Maybe wxHexEditor is more useful than stated earlier. About 350 GB are unallocated disk space. What's the Time Machine volume, the 340 GB volume or the 150 GB volume? — klanomath, Nov 23 '16 at 00:37
The indicated sizes of Paragon and the GUID partition table match: 667388392 blocks of partition 2 = 341.7 GB. But what do the Finder and df entered in Terminal report for "Macintosh HD" on the external drive? Maybe the partition table has wrong entries and the second partition starts at block 409640 and ends near block 1176181368 (instead of block 667798032). I can't really comprehend your 690 GB calculation. — klanomath, Nov 23 '16 at 18:22
Sorry for late response, my family is in town for thanksgiving and I've been with them. Anyway, I can't use the partition right now. The drive is labeled "read only" and I can't seem to change it. I also get an error when I plug in the drive (see image added to post). I know for a fact the partition is around 600 GB. I remember making it and that's what it's been reported as by disk utility up until I tried to "repair" the drive. EDIT: guess the math went wrong somewhere. It's only 600 GB... @klanomath — Jon B, Nov 24 '16 at 05:36
The output of df (and Finder) and gpt are inconsistent with one another: the first two report a size of 601.9 GB while gpt reports 341.7 GB only, but this suggests a solution. I will write an answer soon. — klanomath, Nov 24 '16 at 11:04

klanomath · Accepted Answer · 2016-11-24T21:53:16.157

The GUID partition table of your external disk got hosed somehow and the partition disk1s2 probably has the wrong size: gpt reports a size of ~341 GB but df and Finder suggests that the size is 601 GB. By rewriting the GUID pt this should be solved.

Open Terminal and enter diskutil list and sudo gpt -r show disk1 to get an overview
Unmount disk1:
```
diskutil umountDisk disk1
```

Delete the MBR:

sudo dd if=/dev/zero of=/dev/disk1 bs=512 count=1
diskutil umountDisk disk1

Destroy the GUID partition table and create a new one (this also creates a fresh pMBR):
```
sudo gpt destroy disk1
sudo gpt create -f disk1
```

Rebuild all previous GUID partitions (except the second which will be expanded):

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk1
sudo gpt add -i 2 -b 409640 -s 1175509584 -t 48465300-0000-11AA-AA11-00306543ECAC disk1
diskutil umountDisk disk1
sudo gpt add -i 3 -b 1176181368 -s 292707720 -t 48465300-0000-11AA-AA11-00306543ECAC disk1
diskutil umountDisk disk1
sudo gpt add -i 4 -b 1468891136 -s 146485248 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1
diskutil umountDisk disk1
sudo gpt add -i 5 -b 1787260928 -s 166260736 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1

Finally the gpt table should look like this

gpt show: disk1: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  1175509584      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1175919224      262144         
  1176181368   292707720      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1468889088        2048         
  1468891136   146485248      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1615376384   171884544         
  1787260928   166260736      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1953521664        3471         
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

Adding partition 2 and 3 with these values will leave a gap of 262144 blocks between them which is a standard size for OS X (which itself is a hint that the GUID partition was wrong previously).

verify disk1s2 and disk1s3 afterwards with:

diskutil verifyVolume /dev/disk1s2
diskutil verifyVolume /dev/disk1s3

You still have about 171884544 blocks (~88 GB) of unallocated disk space between partition 4 and 5. If you don't need the backups of the Bootcamp partition you may omit the last two sudo gpt ... commands. You may then expand your Time Machine volume with Disk Utility to ~400 GB.

If you want to add a partition in the unallocated disk space do the following (the instructions will add a JHFS+ partition/volume):

unmount the disk
```
diskutil umountDisk disk1
```
add a new partition with gpt with some free space (2048 blocks) at the beginning and the end. You may also use the standard gap size (262144 blocks) but then you have to use a smaller partition size ... -b 1615638528 -s (171884544 - 2*262144) ... = ... -b 1615638528 -s 171360256 ...:
```
sudo gpt add -i 6 -b 1615378432 -s 171880448 -t 48465300-0000-11AA-AA11-00306543ECAC disk1
```
get the disk identifier of the new partition (88 GB)
```
diskutil list
```

format the drive:

sudo newfs_hfs -v "New" -J /dev/disk1sX #probably X=6

This fixed it. Thank you so much! Except one thing... My time machine partition now shows up as "free space" with the format "unknown." Also, why is there 88 GB of unallocated space and how do I reclaim it? I don't see it in disk utility... I would like to expand the size of my time machine partition. I don't want to delete my bootcamp ones yet if I don't have to. There is tons of unused space in the "macintosh HD" that I would like to repurpose for Time Machine... How can I do this on a mac? Is there a program? Disk Utility won't let me "move" time machine backwards... @klanomath — Jon B, Nov 24 '16 at 20:48
@JonB I don't know why there is so much free space. The free space (initially 350 GB) and the strange/bogus GUID pt was the reason to ask for the history of the disk! Either the app is bogus or you made one or several mistakes. If you added partition 3 (Time Machine) with the old values it should be there - the Time Machine was also bogus though (check your first log result). Moving and resizing partitions is one of the features of Paragon but considering the above problems I would hesitate to use it. — klanomath, Nov 24 '16 at 21:11
@JonB How important is the Time Machine backup? Is it old or new? If you don't repair the disk/single volumes or initialize volumes it is safe to modify the gpt because gpt only writes to the first 34 and last 33 blocks of a disk. BTW I didn't mean a mistake recreating the GUID pt in my instructions, I meant a mistake using the app. I will add a gpt listing how it should look like after applying the changes in my instructions. — klanomath, Nov 24 '16 at 21:25
Apparently I actually did make a mistake following your instructions... (even though that's not what you meant) I just re-ran the instructions and everything checks out now. Fantastic. Thank you!!! Is there a way to "manually" format the unallocated space, just to get it to show up in disk utility? — Jon B, Nov 24 '16 at 21:27
@JonB Yes, there is: simply add a gpt entry with the proper size and the proper type and format it. I will add the instructions to my answer. — klanomath, Nov 24 '16 at 21:32

Partition on HFS+ external drive: "Invalid number of allocation blocks", file system check exit code 8. Unable to repair, even in recovery mode

1 Answers1

Linked