I've upgraded my router from Apple TimeCapsule to Keenetic Ultra. Keenetic supports HFS+ and my external drive enclosure, however when I plug in the drive from TimeCapsule only one 1 GB partition is showing and it doesn't contain any data from the TimeMachine.

  • I'd be wary of continuing to rely on a hard drive if it's over 5 years old.
    – benwiggy
    Sep 13 '20 at 15:46
  • @benwiggy Maybe, but AFAIK they mostly degrade with usage, not from age. Serving as a home file share is much less demanding than being in an actual PC. Despite that I have 2 hard drives form 2007 in PCs, still kicking without errors. Sep 13 '20 at 16:23

This happens because the TimeCapsule disk contains 3 partitions with the same UUID (so much for being Universally Unique) equal to all "0". macOS comes with a utility to assign a new random unique ID to the volume.

You need to attach the TimeCapsule drive to macOS and unmount all partitions (use diskutil list and diskutil info diskXsY to find the disks and ensure the zeroed-out UUIDs, unmount with diskutil umount diskXsY).

After that you can assign new UUIDs for the two 1 GB volumes, leaving the main data volume as-is (just in case).

/System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -s disk2s1
/System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -s disk2s2

This should be enough to get the data volume to show up.

I'm not sure if TimeCapsule expects that UUID to be all 0. If it does then this operation will prevent the drive from working in TimeCapsule, and you can't set the UUID manually using hfs.util. The following snippet is constructed by observing the changes hfs.util -s does to the disk header. This is as safe as open brain surgery, but as far as I can tell the hfs.util only writes 8 bytes to one location on disk, 1128 bytes from the start of the partition. This python script zeroes-out that location, hopefully returning the drive to original state:

with open("/dev/disk2s2", "wb") as f:

All in all, this is very dangerous, make backups, at least of the header portion of the disk, but it still may corrupt data.

UPD: Turns out Apple has open-sourced the hfs.util. I’m correct, this script does all that needs to be done, but the hardcoded offset is still a bad practice, since the FS header may be in a different place on the real disk.

If anyone seriously needs to zero-out the UUID on disk - you should modify the hfs.util itself: https://opensource.apple.com/source/hfs/hfs-183/hfs_util/ Or you can ping me in the comments, I’m willing to do it if anybody actually needs this.

  • Your script should probably print out the original values, just in case. (Also, that's very dangerous; it renders information in the kernel out of date.)
    – wizzwizz4
    Sep 13 '20 at 9:17
  • 1
    @wizzwizz4 It should make a backup of FS header ideally, I’m just lazy. Regarding header - I’m not sure. This changes FS structure on an unmounted drive, header shouldn’t be involved. hfs.util does the same Sep 13 '20 at 11:21
  • *Regarding kernel Sep 13 '20 at 11:40
  • The fact that you can write /dev/disk2s2 suggests that the kernel's aware of the partition table.
    – wizzwizz4
    Sep 13 '20 at 15:35

You must log in to answer this question.

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