Backing up to/from network volumes and other non-macOS-formatted volumes

In addition to backing up to volumes formatted with the macOS standard HFS+ or APFS format (collectively referred to as "macOS-formatted" from here forward), CCC can copy user data files to network volumes (e.g. AFP and SMB via macOS and Windows File Sharing) and to other non-macOS-formatted volumes such as FAT32 or ExFAT. Non-macOS-formatted volumes are presented in CCC's Source and Destination selectors in the same manner as macOS-formatted volumes, so there are no special steps required for backing up to or from these filesystems. However, these filesystems offer limited support for macOS-filesystem features, so special consideration must be given when backing up to these volumes. In general, you can reasonably expect to back up user data — files that belong to your user account — to and from non-macOS-formatted volumes. Specific considerations are noted below.

You can mount network volumes in the Finder, or via the Mount a network volume... option in CCC's Utilities menu. Please note that network volumes mounted by third-party software is generally not supportable.

CCC will only back up system files to or from locally-attached macOS-formatted filesystems

macOS can only be installed on a macOS-formatted volume. This requirement is also carried to a backup volume. When system files are copied to or from non-macOS filesystems, important metadata are unavoidably lost, resulting in files that cannot be restored to their original functionality. In short, you cannot restore a functional installation of macOS from a backup stored on a non-macOS volume. To prevent any misunderstandings about this result, CCC will exclude system files from a backup task if the destination is not a locally-attached, macOS-formatted volume. Likewise, CCC will not copy system files from a network volume, e.g. if you were to mount the startup disk of another Mac via File Sharing, the system files on that network volume cannot be copied in a meaningful way.

Note that the "locally-attached" caveat is an important distinction. Even if your destination volume is macOS-formatted, if it is attached to an Airport Base Station (for example), then you're accessing the volume via file sharing. If you open the Get Info panel for the volume, you will see that the volume format is "AppleShare" or "SMB", not HFS+ or APFS.

Ownership and permissions concerns

Network filesystems pose some interesting challenges in regards to preserving ownership and permissions. When you connect to another computer that is hosting a shared volume, you usually authenticate by providing a username and password. The account whose credentials you provide is an account on that other computer, and it is this account's privileges that determine what access you have to files and folders on the shared volume. Additionally, any files that are copied to the shared volume will be owned by that user account, regardless of the ownership of those files on the source volume. This is not a behavior specific to CCC, it is simply the nature of network filesystems.

An example will be very helpful in understanding the implications of this behavior. Suppose Sally would like to back up some Movies from her Mac's home folder to another Mac shared by Bob and Joe. On Sally's Mac, there is a user account named "sally". On Bob and Joe's Mac, File Sharing has been enabled in the Sharing Preference Pane, and there are two user accounts, "joe" and "bob". Bob has attached an external hard drive named "Backup" to his Mac that he and Joe have been using for backup, and he has created a folder named "Sally's Movies" on this volume to which Sally will copy files. Sally does the following to connect to Bob and Joe's Mac:

In the Finder, open a new window, then click on "Bob and Joe's Mac" in the Shared section of the sidebar.
Click on the Connect as... button.
In the authentication dialog, provide Bob's username and password, then click on the Connect button.
Choose the "Backup" volume from the list of shared volumes.

The Backup volume now appears on Sally's Desktop, and in CCC's Destination selector in the Network Volumes section. Next, Sally chooses Choose a folder... from CCC's Source selector and locates the folder of movies that she would like to copy to Bob and Joe's Mac. She then chooses Choose a folder... from the Destination selector and locates the "Sally's Movies" folder on the Backup network volume. She clicks the Start button and the Movies are backed up.

Later that day, Joe is using his computer and he notices that he can see some of the movies in the "Sally's Movies" folder, but some of the subfolders have a universal "No access" badge and he cannot view those folders' contents. This occurred for two reasons:

Sally mounted the network volume using Bob's credentials, so the files and folders created when she copied her files to the Backup volume are now owned by Bob's user account.
Some of the folders on Sally's computer prevented access by "other" users.

As a result, the folders on the Backup volume are owned by Bob and some of them limit access to other users (Joe in this case). Joe asks Sally about this and she decides to try copying some of the movies to one of Joe's folders on the backup volume. When she chooses Choose a folder... from CCC's Destination menu, however, she sees the same universal "No Access" badge on Joe's folder. Sally can't copy files to this folder (nor can CCC) because the Backup volume was mounted using Bob's credentials, and Joe's backup folder on the backup volume happened to be inaccessible to Bob. Sally unmounts the backup volume and reconnects to it using Joe's credentials, and she is then able to copy files to Joe's private folder.

What can I do when there are permissions or ownership issues that prevent CCC from copying items to/from or updating items on a network volume?

First, it is important to keep in mind that no application can modify the ownership of a file or folder on a network share. Ownership changes must be applied on the computer or device that is hosting the network volume. Additionally, permissions changes can only be made to files and folders owned by the user whose credentials were used to mount the network volume. For this reason, it is generally easier to apply both ownership and permissions changes on the computer or device hosting the network volume.

If the computer hosting the network volume is a Mac, you can modify ownership and permissions in the Get Info panel for that folder (on the Mac hosting the network volume):

In the Finder, click on the folder whose permissions or ownership you would like to change.
Choose Get Info from the File menu.
In the Sharing & Permissions section at the bottom, click on the lock icon to make the permissions editable.
To change permissions, choose Read & Write from the popup menu next to the owner of the file or folder.
If the owner of the item is not the user account that you use to connect to this Macintosh, click on the + button
In the window that appears, select the user account that you use to connect to this Macintosh, then click the Select button.
Set the access privileges to Read & Write.
Click on the "additional actions" menu and choose to apply the change to enclosed items.
Try your backup task again.

If the computer or device that is hosting the network volume is not a Macintosh, consult that device's documentation to learn how to change permissions and ownership of files and folders.

Alternative #1: If you have mounted the network volume with Guest privileges, unmount and remount the network volume using the credentials of an account on the machine or device hosting the network volume.

Alternative #2: You can create a new folder on the shared volume and specify that folder as the destination in CCC by choosing Choose a folder... from the Destination selector.

Alternative #3: You can have CCC create a disk image on the network volume rather than copying files directly to a folder. When CCC creates a disk image on the destination, the disk image is formatted to match the source and attached locally, so CCC can preserve the permissions and ownership of the files that you are copying to it.

Why can't I change the username when CCC prompts for NAS volume credentials?

When you select a NAS volume as the source or destination to a CCC task, CCC will prompt for the credentials that were used to mount that volume. CCC already knows the user name for that volume, that value is published in the "filesystem URL" attribute of the mounted NAS volume (you can type mount into the Terminal application to see that value). CCC asks for the password so that CCC can remount the NAS volume automatically later. In order to avoid ownership or permissions issues, CCC will remount the NAS volume using the exact same user account that was used to mount the NAS volume in the Finder – this is why the username field cannot be modified.

If you would like to use a different user account to mount the NAS volume, then you should eject the NAS volume in the Finder and remount it using the preferred user account. Once the volume is remounted, reselect the NAS volume (or a folder on that NAS volume) as the source or destination to your task. If CCC does not have the credentials for the user account that was used to mount the NAS volume, CCC will again prompt for those credentials.

Limitations of non-macOS-formatted filesystems

When you choose a non-macOS-formatted volume as a destination, CCC's Cloning Coach will proactively warn you of any compatibility issues between the source and destination volumes. You can view the Copy Coach's warnings by clicking on the yellow caution button in the Task Plan box. If you have selected a source and destination volume, and the caution button is not present, then there are no configuration concerns.

Support for third-party filesystems

CCC offers limited support for third-party filesystems, such as those provided by FUSE for OS X. Due to the large number of filesystems that can be provided by FUSE, CCC provides generic support for these "userland" filesystems rather than specific support. CCC takes a best effort approach by determining the capabilities of the source and destination filesystems, warns of potential incompatibilities, then presents only unexpected error conditions that arise during a backup.

Backing up to FUSE volumes mounted without the allow_root flag is not currently supported (e.g. Google Drive, BitCasa). Please contact the vendor of your proprietary filesystem to ask that they offer the ability to mount the volume with the allow_root flag if you would like to use that volume as a source or destination to a CCC backup task.

Support for Google Drive is "best effort". We've seen odd behavior when selecting 'Google Drive for desktop' volumes as a whole as the source or destination for a task – CCC is unable to read the root folder during a backup task. CCC explicitly disallows that configuration. Selecting a subfolder on the Google Drive volume often works, and CCC will not disallow that configuration, however we frequently receive reports of inconsistent results when backing up to Google Drive, so we cannot offer support for this configuration.

There is one other notable concern with 'Google Drive for desktop' – Google Drive will download files when they are accessed if they do not currently reside on your Mac's hard drive. If you specify a Google Drive folder as the source to a backup task, you should anticipate that cloud-only files may be downloaded to your Mac during the backup task. That behavior lies outside of CCC's purview, it cannot be modified with a CCC task setting.

The Western Digital MyCloud Home NAS device is another special case. The "Home" model of this NAS device requires the use of WD-proprietary software to access the storage securely; direct access to the storage via SMB is only available with Guest privileges. Users report that performance of the storage while using WD's software is subpar in comparison to Guest access via SMB, and other users have reported to us that macOS is unable to create or mount disk images on the storage when mounted via Western Digital's software. When you mount WD MyCloud Home NAS storage using WD's software, the volume is vended by a 'kddfuse' filesystem. CCC won't allow these volumes as a source or destination device. To back up to a WD MyCloud Home NAS, mount the storage via SMB in the Finder instead. Be sure to choose the "Guest" user option when prompted to authenticate, because the MyCloud Home device doesn't support authenticated access via SMB.

Writable NTFS filesystems

We have seen several reports of problems copying large amounts of data (e.g. > 4GB) to writable NTFS filesystems. In most cases, the underlying software that vends the filesystem (e.g. Tuxera, Paragon, and others) crashes and the volume is rendered "mute". While it may be possible to complete a backup to these filesystems in chunks (e.g. 4GB at a time), we recommend using a more reliable, writable filesystem if you encounter these problems.

Backing up a Boot Camp installation of Windows

CCC can back up the user data on a Boot Camp volume, but it cannot make an installation of Windows bootable. If your goal is to back up your user data on the Boot Camp volume, CCC will meet your needs. If you're looking to migrate your Boot Camp volume to a new hard drive, you might consider an alternative solution such as WinClone, or one of the commercial virtualization solutions that offer a migration strategy from Boot Camp.

Backing up the contents of an NTFS volume

The NTFS filesystem supports "named streams", a feature that is comparable to extended attributes on macOS-formatted volumes and many other filesystems. Unlike extended attributes, however, there is no limit to the amount of data that can be stuffed into NTFS named streams (aside from standard file size limitations). Extended attributes on macOS have a 128KB size limit. As a result, any attempts to copy a named stream larger than 128KB to a non-NTFS filesystem will fail. CCC will copy the standard file data just fine, but will not copy named streams larger than 128KB. CCC's Copy Coach will warn of this kind of incompatibility, and any errors related to this limitation will be logged to the CCC log file, however these errors will not be raised to your attention.

This limitation applies when copying files between volumes on Windows as well, so application developers tend to use named streams only for data that can be regenerated (e.g. thumbnail icons, summary or statistical information), not for storage of irreplaceable user data.

NAS service failures can lead to unreliable backups

Access to the contents of a network volume is provided by an application that runs on another computer or Network Attached Storage (NAS) device. Every NAS device and operating system has its own vendor-specific version of the file sharing application, so we occasionally see problems with some NAS devices that don't occur on others. Problems can be minor, such as being unable to set file flags (e.g. hidden, locked) on an item, or more significant, like not being able to store or retrieve resource forks. When these problems are encountered during a backup task, CCC will copy as many files and as much data as possible, then offer a report on the items or attributes that could not be copied.

When you encounter an error caused by the file sharing service that hosts your network volume, there are a few workarounds that you can try to avoid the errors:

Eject the network volume on your Mac, then restart the computer or NAS device that is hosting the network volume. Reconnect to the network volume and try the backup task again.
Connect to the network volume using a different protocol. A different application is responsible for each protocol, so if the AFP service on your server has a bug, connecting to the SMB service may work more reliably (and vice versa). Follow these steps to connect to the server using a different protocol:
1. Eject the NAS volume if it's currently mounted
2. Open CCC and select the applicable backup task
3. Click on the Source or Destination selector (whichever is applicable for your particular task)
4. Hold down the Option key and choose "Switch to {the other protocol}" (provide the credentials for the NAS volume again if prompted)
5. Save and run the task
If the errors persist when connecting to the network volume via both AFP and SMB, and restarting the file server does not change the outcome, then we recommend that you back up to locally-attached storage instead.

Some NAS services have obtuse file name restrictions

Some NAS file sharing services will automatically rename files to "DOS compatible" names, or simply issue errors when working with various file names. In particular, files or folders that start or end with a space character, or names that contain a colon (:) or slash (/) character are unacceptable. When the file sharing service encounters files or folders with these disallowed characters, it will either report an "invalid argument" error, or it will automatically rename these items, e.g. " filename.txt" would become "_1CZVG~B". This "mangling" of file and folder names inevitably leads to errors during a backup task.

Non-ASCII characters (e.g. é, ö) can also lead to conflicts on NAS volumes. If you see errors where each "affected item" has a non-ASCII character somewhere in its path, refer to Character composition conflicts on NAS volumes to see how to identify and resolve the issue.

Another common issue that people encounter when copying files to a NAS volume is errors that are the result of a name restriction. For example, Synology NAS devices (and many others) disallow file names that start with .lock, CON, PRN, AUX, NUL, COM0 - COM9, LPT0 - LPT9, _vti_, desktop.ini, any filename starting with ~$. These NAS devices often produce bogus error codes in these cases, e.g. "File name too long". Some NAS devices have specific character restrictions as well, e.g. NAS devices that follow the Microsoft OneDrive naming conventions, which exclude " * : < > ? / \ |, and leading and trailing spaces in file or folder names also aren't allowed. Many people run into this same problem when making backups of the GarageBand application because there is a folder in the application bundle named "Aux".

There are three different ways to avoid these errors:

Rename the offending files or folders on the source

If you're only seeing this error on a handful of files, then renaming the files on the source to appease the Windows naming conventions may be the simplest way to resolve the errors. Do not attempt to rename folders that reside inside of an application bundle, though (e.g. GarageBand.app).

Connect to the NAS device using AFP instead

Windows naming conventions are typically only applied by the SMB file sharing service, so you may be able to connect via AFP instead to avoid the NAS limitation. Note that some NAS devices no longer support AFP, so this workaround may not be an option in your case.

Eject the NAS volume if it's currently mounted
Open CCC and select the applicable backup task
Click on the Source or Destination selector (whichever is applicable for your particular task)
Hold down the Option key and choose "Switch to AFP" (provide the credentials for the NAS volume again if prompted)
Save and run the task

Change the SMB service configuration on the NAS

If your NAS device allows changes to its SMB configuration, you can add "mangled names = no" to the end of its smb.conf file to disable SMB name mangling (that setting is documented here). We can't offer documentation on how to do this for every NAS device available, but we do a fair amount of testing against Synology's DiskStation, and the procedure goes like this:

Connect to the DiskStation via ssh (e.g. in Terminal, ssh admin@fileserver.local)
Append the smb.conf file:
sudo -s echo "mangled names = no" >> /etc/samba/smb.conf
Unmount, then remount your NAS volume, then try running your CCC backup task again

Please note that this change is explicitly not supported by Synology (nor us), so proceed at your own risk. We have, however, submitted a feature request to Synology to add support for changing this setting in the Disk Station Control Panel. It's the 2020s, Windows naming conventions from the 1990s are a bit archaic at this point.