Backing up to/from network volumes and other non-HFS volumes

In addition to backing up to volumes formatted with the macOS standard "HFS+" format, CCC can back up user data to network volumes (e.g. AFP and SMB via macOS and Windows File Sharing) and to other non-HFS+ formatted volumes such as FAT32. Non-HFS+ formatted volumes are presented in CCC's Source and Destination selectors in the same manner as HFS+ formatted volumes, so there are no special steps required for backing up to or from these filesystems. However, these filesystems offer limited support for HFS+ 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-HFS+ formatted volumes. Specific considerations are noted below.

Instructions for gaining access to network filesystems is available in the macOS Help Center. If your network volume does not appear in CCC's Source or Destination selector, consult the documentation that came with the storage device you are trying to access, or choose "Mac Help" from the Finder's Help menu and search for "connecting to servers".

CCC will only back up system files to locally-attached HFS+ filesystems

macOS can only be installed on an HFS+ formatted volume. This requirement is also carried to a backup volume. When system files are copied to non-HFS+ filesystems, important metadata are invariably 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-HFS+ volume. To prevent any misunderstandings about this limitation, CCC will exclude system files from a backup task if the destination is not a locally-attached, HFS+ 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, 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 HFS+ 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", not HFS+. It is not possible to update an OS backup on a network volume. If you would like to maintain a backup of macOS on a network volume, you can back up to a disk image on the network volume. See the related documentation below for additional information on this backup strategy.

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 Clone 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 sharepoint. 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 sharepoint is a Mac, you can modify ownership and permissions in the Get Info panel for that folder (on the Mac hosting the sharepoint):

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 Gear menu and choose to apply the change to enclosed items.
Try your backup task again.

If the computer or device that is hosting the sharepoint 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 as HFS+ and attached locally, so CCC can preserve the permissions and ownership of the files that you are copying to it.

Limitations of non-HFS+ filesystems

When you choose a non-HFS+ 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 Cloning Coach's warnings by clicking on the yellow caution button in the Task Plan header. 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. PogoPlug, 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.

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 HFS+ 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 Cloning 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.

Resource limitations encountered while backing up resource forks to/from AFP volumes

We have received sporadic reports of a problem that can occur while copying files to or from some Apple File Protocol sharepoints (e.g. a volume shared from another Macintosh using the "File Sharing" feature of the Sharing preference pane). When the problem occurs, the server erroneously maintains open references to hundreds of resource forks. Eventually the file sharing service encounters a system-imposed resource limitation and is unable to continue sharing files until it closes the open resource fork files. Misleading errors are subsequently returned to CCC, reported as "Input/output" errors or "Bad file descriptor" errors. CCC will report that "An error occurred while CCC was getting or setting information about this item on the source/destination".

This problem is due to a bug in the AppleFileServer application, and affects several different implementations of the AppleFileServer (e.g. on macOS as well as on some other NAS devices). We have identified a few solutions/workarounds to try when encountering this problem:

Unmount the sharepoint, then restart the Macintosh or Network Attached Storage device that is hosting the AFP sharepoint. Reconnect to the sharepoint and try the backup task again.
Connect to the sharepoint using SMB instead of AFP. Choose "Connect to server" from the Finder's Go menu, then specify "smb://servername.local/sharepoint " to connect to the server using SMB rather than AFP. Then drag the network volume onto the source or destination selector for your CCC backup task so that the task will use SMB rather than AFP to connect to the sharepoint.
Reduce the number of files/folders in your backup set, e.g. split your backup task into multiple tasks.

"This error may have been caused by a problem with the file sharing service that hosts your network volume."

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 sharepoint. Reconnect to the sharepoint and try the backup task again.
Connect to the sharepoint 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). Choose "Connect to server" from the Finder's Go menu, then specify "smb://servername.local/sharepoint " or "afp://servername.local/sharepoint " to connect to the server using a different protocol. If you are unsure which protocol you are currently using, click on the mounted volume in the Finder, then choose "Get Info" from the Finder's File menu to find out.
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, try backing up to a disk image on the network volume instead.