Catalina reorganized the Mac boot drive. When Catalina is installed the boot drive is converted from one logical volume (HFS or APFS) to a collection of 2 APFS logical volumes, a read-only volume with the same name as the original boot drive and a read-write volume name ‘[boot drive] - Data’. Note that you only see this structure when running Disk Utility or other disk maintenance programs; in the Finder, there is only the single drive icon as usual.
This week, I migrated my old iMac to a new iMac. New machines come with the boot drive name ‘Macintosh HD’, but I always change it to reflect the actual machine. I have always done this by renaming the drive in the Finder by clicking the drive name and typing a new name, in this case, iMac 5K Disk.
Everything ran fine until I fired up Carbon Copy Cloner for the first time. When I tried to run a cloning task, I was told ’ The source volume was not available when CCC attempted to run this backup task’. I checked the ‘iMac 5K Disk’ was identified as the source volume for the task and got the same error. I opened Disk Utility and noticed that the Data volume was still named ‘Macintosh HD - Data’. So, I needed to rename the Data volume via Disk Utility as ‘iMac 5K Disk - Data’. Once I did that, I was able to create a proper clone of the boot drive.
The information about drive naming and Disk Utility solves something I’ve been puzzling over, which was why BackBlaze was using a hard disk’s original name and not the one that shows on the Desktop.
Looks like a side-effect of Apple’s use of an overlay-style file system (e.g. OverlayFS or UnionFS). These file systems combine two or more physical file systems in a way more complicated than the traditional mount point mechanism used by HFS+.
These mechanisms are intended to hide the structure of the underlying file system volumes, allowing volume-level protections to be applied at what seems (to the user) to be at a per-file or per-directory granularity. They also allow copy-on-write semantics, so users that “edit” a file end up secretly making a copy, leaving the original intact in its original location.
Given the error reported by CCC, it would appears that it is accessing the underlying volumes (probably necessary for a reliable clone) and is not going through the normal overlaid file system. But it is definitely Apple’s bug that renaming the overlay doesn’t propagate down to the names of its underlying volumes.
I can think of two possible fixes:
Apple updates the Finder so renaming an overlay-volume causes the underlying volumes to be appropriately renamed
CCC adds some logic to check for this. Verify the name against the Finder-visible name and then go look up the names of the underlying volumes.
Given what I know about the people/companies involved, I suspect the latter will be more likely to happen.
It’s not clear this is a bug in macOS. macOS could use roles to determine what volumes to mount and how to treat them, and their names are just set the same (but for the - Data suffix) by default, and nothing in macOS actually depends on those names. That’s arguably more robust. CCC would then be making an unwarranted assumption, and should instead be doing what macOS does, which would remove the problem and be a bit more future-proof (as the number of available roles is being expanded greatly in Big Sur.) While it might be nice that a rename on one volume renames the other, if macOS doesn’t need it, I can understand why it doesn’t happen.
There are no CCC nor macOS bugs here, it’s normal and correct for CCC to indicate that the source volume is not available when you migrate your data to a new Mac. CCC isn’t making any assumptions here either – indeed, the old Mac’s “Macintosh HD” volume is not available on the new Mac, the new Mac has its own “Macintosh HD” volume. CCC doesn’t rely on the volume name alone for identification, it uses the volume’s universally unique identifier.
So, I needed to rename the Data volume via Disk Utility as ‘iMac 5K Disk - Data’. Once I did that, I was able to create a proper clone of the boot drive.
Renaming the Data volume has no effect on CCC’s identification of the source or destination, CCC never considers the name of the Data volume (as you suggested, CCC uses volume roles alongside the UUID to identify the Data volume). Alan must have reselected the Macintosh HD volume as the source, that’s the only thing you need to do to get the task configured correctly for a new Mac.
Thanks for responding. However, as I recall, I did reselect the boot drive in CCC with no effect until after I changed the name of ‘- Data’ volume and reselected the boot drive in CCC. Frankly, even if CCC works without needing to rename the volume, I think not automatically renaming it is a bug on Apple’s part. In the Finder, the disk icon for the boot disk represents both volumes. With the names ganged together, a user looking at a disk utility gets a clue to the association, but letting them have different base names hides that relationship.
P.S. I remember going up to you at the first Macworld expo after you released CCC. I had delayed upgrading to OS X until a user-friendly backup utility was created, and you did it. The only problem was that you had no provision for accepting any shareware payment. So, when the doors opened, I went to your booth first and handed you cash ($5, I think).
@bombich Mike, just want to thank you for a great program and even better the level of support you provide your customers - especially dummies like me lol. CCC has been a life saver for me numerous times. Also, when I have asked for help your folk have responded promptly and with a clarity that allowed me to do what was needed.