Occasionally this annoying message comes up when you're trying to eject your destination volume. If CCC is currently using that volume as a source or destination to a running backup task, then CCC will effectively prevent the volume from being unmounted. If your backup task is not running, though, CCC isn't preventing the volume from being unmounted. But what application is?
If this occurs within a minute or so after the backup task completes, it's typically caused by a macOS or third party service that is scanning or reindexing content that was just copied to the backup volume. Those processes usually finish after a minute or two, and usually the destination can be ejected when that completes. If this frequently affects your backup volume, you can ask CCC to unmount the destination after the backup task completes. CCC will make multiple attempts to unmount the destination, resulting in a more reliable (and automated!) ejection of the destination at the end of the backup task:
- Open CCC and select your backup task
- Click the Advanced Settings button
- In the Postflight tab, choose the option to unmount the destination volume after the backup task completes.
- Click the Done button, save and run your backup task
If the volume cannot be unmounted several minutes after the backup task has completed, or if CCC is also unable to eject the destination, open CCC's Task History window and view the error noted in the Errors tab for more information, if available, about the identity of the dissenting application.
Applications that frequently prevent volumes from unmounting
We've received (and confirmed) reports of the following applications causing trouble with volume unmounts. If you have one of these applications, you should see if you can add your CCC backup volume to a "whitelist" within that software to avoid the interference it causes. The name of the offending process (which is what you would see in the Console application) is noted in parentheses.
- BitDefender (BDLDaemon)
- Time Machine (backupd)
- Spotlight (mds or mds_stores)
- Disk Drill (cfbackd)
- Retrospect (RetrospectInstantScan)
- CleanMyDrive
- Intego Virus Barrier (virusbarriers)
- AppCleaner (AppCleaner SmartDelete)
- AVG AntiVirus (avgoad)
- ClamXAV
A deeper technical analysis of volume unmounting
When you attempt to unmount a volume, the unmount request goes to the macOS DiskArbitration service (which is implemented by a service named "diskarbitrationd"), which goes through several steps to effect the unmount.
System-wide unmount notification
When DiskArbitration receives an unmount request, it sends out a notification of the request to any application that has subscribed to "unmount notifications". Any application that subscribes to these notifications has an opportunity to dissent the unmount request. CCC, for example, subscribes to these notifications and dissents volume unmount requests for the source and destination volumes involved in any currently running backup task. If no task is running that involves the affected volume, CCC returns an "allow" response.
Applications that subscribe to these requests are obliged to respond in a reasonable amount of time — dissent, or allow. Not responding is rude, and unnecessarily delays the unmount request.
When an application replies to DiskArbitration with a dissent response, they also have the opportunity to include a comment. Using CCC as an example again, CCC will dissent with a comment like "The Carbon Copy Cloner task 'Hourly Backup' is currently running a backup task to this volume." Sadly, macOS does not present these comments in the Finder, nor does it consistently present even the name of the dissenting application.
Attempt to unmount
If no application dissented the unmount request, DiskArbitration will attempt to unmount the volume. At this point, the volume should unmount! If any application has an open file on the affected volume, however, the unmount request will fail. Occasionally the ensuing dialog will indicate which application is using the volume, but often you get a very generic message that the disk wasn't ejected, "because one or more programs may be using it."
Finding the offending file and application
If you've just seen a dialog that a volume can't be ejected, you can find the offending item in the Terminal application. Open the Terminal application and paste in the following:
sudo lsof | grep "CCC Backup"
Replace "CCC Backup" with the name of your own backup volume, then press the Return key. You will be prompted for your admin password; enter your password, then press the Return key again. The "list open files" utility will print a list of open files specific to that volume, and will include the name of the application that has the open file reference.
It's usually Spotlight
More often than not, some Spotlight process is retaining an open file on the backup volume and preventing it from being unmounted. If you find "mds" or "mds_stores" listed in the lsof output, you can disable Spotlight on your backup volume to prevent the interference. To disable Spotlight, open System Settings > Spotlight, scroll down and click "Search Privacy…", then drag the backup volume into the Privacy table. This only affects the selected volume, and it's reversible, you can remove it from that list should you decide that you want to re-enable indexing.
Once you have disabled Spotlight indexing, Spotlight should immediately cease indexing activity on that volume. The same underlying problem that might be causing Spotlight to fail to release an open file, however, (e.g. a stall) may also prevent Spotlight from ceasing the indexing activity. If you are still unable to unmount the volume after a) confirming that it was Spotlight with an open file, and b) adding the volume to the Spotlight Privacy table, you can either terminate the mds and mds_stores processes in the Activity Monitor application, or simply restart the system.
Sometimes Spotlight is so hung up, you can't add the volume to the Spotlight privacy list
We have recevied several reports from Sequoia users that the suggestion to add the backup volume to Spotlight's privacy table does not work; System Settings issues an error, "The item couldn’t be added or removed because of an unknown error". Clever users have attempted to use the mdutil command-line utility to disable Spotlight on the backup volume, but that also fails, "Error: unable to perform operation. (-400)". If you find yourself in this position and you're comfortable in the Terminal application, you can try the following steps to manually exclude a volume from Spotlight indexing:
- Quit the Terminal application if it is open
- Grant Full Disk Access to the Terminal application in System Settings > Privacy & Security > Full Disk Access
- Open the Terminal application and then open the Spotlight configuration file on your backup disk for editing:
sudo pico "/Volumes/CCC Backup/.Spotlight-V100/VolumeConfiguration.plist" - Add this block right after the "<dict>" line towards the top:
<key>Exclusions</key>
<array>
<string>/</string>
</array> - Press Control+X, then type 'Y' to save and exit.
- Unmount the backup volume (forcefully, if necessary), then remount the volume. Spotlight indexing should now be disabled on that volume.