Macos – How to restore from a sealed APFS volume when restore fails “because it has a broken seal”

apfsdisk-utilitymacosmacos-bigsur

I have been researching this for many hours over the last week. A description of my research effort is at the end of this post.

Disk Utility will not restore an APFS volume "because it has a broken seal," but the volume appears to be sealed.

The source is the internal SSD in a 2013 Mac Pro. The target is a Thunderbolt-connected SSD.

Disk Utility's log:

Restoring “Container disk5” from “Macintosh HD”

Validating target...
Validating source...
The source volume cannot be restored because it has a broken seal
Could not validate source - Invalid argument
The operation couldn’t be completed. (OSStatus error 22.)

Operation failed…

csrutil authenticated-root status returns: Authenticated Root status: enabled which suggest that the volume is currently properly sealed.

Efforts So Far

booted into recovery mode (same issue)
booted from a third SSD with a full fresh install of macOS Big Sur (v11.1) (same issue)
switching the source to be connected via Thunderbolt and the target as the internal drive (same issue)
used another computer, a MacBook Air, (same issue)
used Apple Software Restore command sudo asr restore --source /dev/disk1 --target /dev/disk5 --erase where disk1 is the source APFS Container and disk5 is the destination APFS container (same issue)
attempted to create a disk image of the volume, so I could attempt to restore with the disk image as the source (other issue described under research effort below)
created a disk image of the APFS Container and attempted to restore with the disk image as the source (other issue described under research effort below)
created a disk image of the disk and attempted to restore the disk image as the source (other issue described under research effort below)

Involved Software

macOS Big Sur (v11.1 build 20C69) This was originally something like v11.0.1 installed to a fresh drive about November or December 2020 (two to three months ago) to a freshly wiped SSD.
Disk Utility 20.0 (1714)

Research Effort

Currently a Google search for "The source volume cannot be restored because it has a broken seal" results in only seven results (two are broken links, two are not applicable, two are from when macOS Big Sur (macOS 11) was in beta, and only describe the problem, and one is a copy of another result).
Google results for the less restrictive unquoted version of the query largely result in completely unrelated results; the few related results are duplicates of the previously described seven results, or results that talk about the inner workings of APFS and the new sealed volume feature which, described next
So, as finding a direct solution that someone else has already found is a dead end, I have worked to learn everything that I can about the new sealed volumes, which has been no help to me in solving this issue.
My attempt using an image file instead of a direct restore results in other issues. Three different issues arise depending on which level—volume, container, or device—is selected for the disk image. The most promising of these had an issue which my research showed is seemingly related to macOS Big Sur (macOS 11) APFS boot volumes having snapshots after updates. I may post as a separate question for that issue if direct resolution of this question is elusive, and further attempts to resolve that issue fail.

Best Answer

I also ran into this issue while trying to use Disk Utility to copy the contents of the internal SSD of my Mac Mini (2018, macOS v11.2.1 (Big Sur)— however this was happening on 11.1.x as well) onto an external drive.

After doing some research, I found out that the restore function on Disk Utility has been historically finicky and slow. An alternative workaround that I found was to use Carbon Copy Cloner (CCC). CCC is able to copy the contents of a bootable MacOS disk to another disk on Big Sur (Intel chips only, there is a bug preventing this to work on Apple Silicon chips). I tested this myself and it does work and it is also outlined in this blog post from CCC.

Using an external piece of software may not be the answer you were looking for, however CCC seems superior to the Disk Utility restore function even if it was working. It is faster, and also can copy the disk you are currently booted onto, where Disk Utility requires you to be in Recovery mode for this option.

Related Solutions

How to resolve APFS overallocation error from volume “VM” without reformatting disk

So I did little experimenting and it seems the problem may indeed simply be a result of trying to verify the APFS container, rather than one of its volumes, at least when it's the system volume that you're checking.

In a typical setup your output from diskutil might look something like this:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         1000.0 GB  disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk1
                                 Physical Store disk0s2
   1:                APFS Volume macOS                   74.9 GB    disk1s1
   2:                APFS Volume Preboot                 44.6 MB    disk1s2
   3:                APFS Volume Recovery                506.8 MB   disk1s3
   4:                APFS Volume VM                      20.5 KB    disk1s4

In this case verifying the container (diskutil verifyVolume disk0s2) seems like it should work, but even on a newly formatted disk it can result in odd errors, that then either don't occur when checked again, or don't occur when checking from recovery or another startup disk.

Interestingly however, verifying the container itself appears to be fine when dealing with a second (non-system) APFS drive, for example if the layout looks something like this:

/dev/disk0 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         4.0 TB     disk2s2

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +4.0 TB     disk3
                                 Physical Store disk2s2
   1:                APFS Volume Data                    2.67 TB    disk3s1

In such a case it seems verifying the container versus verifying the only volume in it, are functionally equivalent.

Why there should be a difference, I have no idea. Whatever the cause, it seems that for checking the system volume at least that it may be best to check only specific volumes, like so:

diskutil verifyDisk disk0
diskutil verifyVolume disk1s1

In theory APFS should be more resilient to corruption than HFS+ anyway, since all the metadata is supposed to be checksummed now.

That said, I have had a system volume go bad under APFS, but this was a result of a power loss, resulting in a snapshot being left in a broken state (couldn't remove it using tmutil or diskutil apfs deleteSnapshot, requiring a full erase to fix it). I run checks mostly out of paranoia to keep an eye out in case it ever happens again (newer fsck_apfs versions may also be able to fix such issues, I'm not sure).