Saltar al contenido principal

macOS Ventura Known Issues

  • Actualización

Apple published macOS Ventura in November 2022. CCC 6.1.3 (and later), published in September 2022, is fully compatible with macOS Ventura. We cite known problems that Apple introduced in the new OS below.

Some backup volumes don't appear in the Finder (sidebar, nor Desktop, nor Computer)

If you created a bootable copy of Catalina, Big Sur, or Monterey in the past, and then proceed with CCC backups to that volume on Ventura without specifically using the Legacy Bootable Copy Assistant, CCC will remove the incompatible System volume from the destination. Prior to Ventura, the remaining Data volume would appear just fine on the Finder Desktop, and also in the volume list when you select "Computer" from the Finder's Go menu, but not in the sidebar. In Ventura, this volume no longer appears in any of these locations, regardless of your Finder preferences to show external volumes in the sidebar, and regardless of any attempts to drag the volume explicitly into the sidebar.

We reported this issue to Apple (FB9739492) in November 2021. Apple never replied, and only made the problem worse in Ventura. Hopefully we'll see this issue less frequently as people migrate away from legacy bootable copies of macOS.

Workaround: You can create an alias of the volume on your Desktop:

  1. Click Volumes in CCC's sidebar
  2. Right-click on your backup volume in CCC's sidebar and choose Reveal in Finder
  3. Choose as Columns from the Finder's View menu
  4. Hold down Command+Option while dragging the revealed volume to your Desktop to create an alias

Solution: Erase the volume in Disk Utility and start the backup from scratch. The underlying cause of this problem is the presence of an irrevocable "Data" role applied to that volume by Apple's ASR replication utility. macOS has documented functionality to remove that role, but that functionality does not work (FB7208067, Sept 2019). Erasing the volume is the only remaining recourse.

ExFAT filesystem corruption

We're tracking a new ExFAT-specific filesystem bug in macOS Ventura. We have seen a handful of cases where a folder's inode number is identical to the inode number of its parent folder. Some filesystem enumeration facilities (e.g. fts) identify this (correctly) as an insane "directory cycle" (i.e. infinite loop) condition and refuse to enumerate the content of the corrupted subfolder. CCC (6.1.4+) identifies this result, reports it as an error, and suspends any deletion/archival activity on the destination when this condition is encountered to avoid errantly removing content from the destination that was copied in a previous backup task.

In the handful of cases we're tracking, the issue appears to be both transient and recurrent, e.g. sometimes the condition is absent when running the task again at a later time, and sometimes it recurs immediately after remounting the source volume. We have seen other related aberrant behavior on these volumes, e.g. folder inode numbers change when the volume is remounted. These aberrations are harmless as far as a backup/file copying task is concerned, but could cause trouble for other applications that expect folder inode numbers to be constant.

We consider this a serious filesystem bug, however we are not concerned that this will lead to data loss on ExFAT source volumes. This bug is exposed only when performing a complete enumeration of the volume starting from the root folder, it's not something that would necessarily affect the collection of an individual folder's content (e.g. in the Finder). Regardless, this condition is not sane and could lead to unexpected results from applications that are not guarding against this kind of filesystem corruption. Our recommendation right now is to avoid using ExFAT on macOS Ventura if you're not specifically using that filesystem to share files with a non-macOS device. Except when required to share files with a non-Mac system, ExFAT is generally a poor choice on macOS. It's very slow on macOS (usually 2-4x slower than APFS), and uses space much less efficiently.

We have reported this bug to Apple (FB11834215, November 29, 2022) and we are currently waiting for a response.

Workaround: A "folder swap" on the source should resolve individual occurrences of this problem. For example, if CCC identifies that a folder named "Projects" is affected, then you would:

  • Create a new folder adjacent to "Projects" named "Projects-new" [on the source volume]
  • Move the content of "Projects" into the "Projects-new" folder
  • Move the (now empty) "Projects" folder to the Trash
  • Rename "Projects-new" to "Projects"
  • Run your CCC backup task again to complete the backup

Solution: After you have resolved any corrupted folder issues (see above), you can do the following to migrate your data away from the ExFAT volume:

If you have any concerns about this procedure, or you would like a review of your case prior to erasing the source, please don't hesitate to ask us for help. We greatly prefer to get involved before you erase your source if you have any questions or nagging concerns about the procedure.

Apple's APFS replication utility ('asr') may fail to produce a bootable USB device on Apple Silicon Macs

When using the Legacy Bootable Copy Assistant on an Apple Silicon Mac running macOS Ventura, the resulting volume may not be bootable if it resides on a USB-attached device. ASR can produce bootable copies to the same device on an Intel Mac. This does not appear to be a general shortcoming of USB devices on this platform, rather it appears to be a shortcoming of the Apple asr utility.

Workaround: Use a Thunderbolt device if you're trying to make a bootable copy of macOS Ventura on an Apple Silicon Mac.

Workaround: If you only have access to a USB device, proceed with a Standard Backup (do not use CCC's Legacy Bootable Copy Assistant). When the backup is complete, open the Ventura Installer (or boot into Recovery Mode) and proceed to install Ventura onto the USB device.