How to setup TimeMachine on a network drive with disk quota
Wednesday, October 17th, 2012 11:45 pm GMT +2

Well, once you bought your NAS or configured a dedicated PC with network drive you’ll obviously want to setup Time Machine. The problem is, once configured to backup to a networked drive your TimeMachine will eat all available space.

For those lucky ones, who shared a dedicated disk partition on their drive — there’s no problem at all. But I was not one of them. Recently, I’ve purchased a used Buffalo LS-WXL Linkstation duo inserted two new 1TB drives and configured it as a RAID0 array. As a result, almost whole 2Tb partition became available for sharing — despite how hard I tried to figure out xfs quotas on target partition, no success.

Well, there are bad and good news.

  • The good news is that you may limit your Time Machine disk quota by using something called sparse disk bundles.
  • The bad news is that you’ll need root access to your NAS in order to apply permissions hack to make it work with latest versions of Time Machine

Let’s proceed!

Create sparse bundle on your mac

Open terminal, and create 1024g sparse disk:

# Get the MACADDR of network port
$ MAC=$(ifconfig en0 | perl -ne 's/.*ether (\w+:\w+:\w+:\w+:\w+:\w+).*/$1/ && s/://g && print;')
$ echo $MAC

# Create name of sparsebundle
$ SBNAME=$(hostname)_$MAC.sparsebundle
$ echo $SBNAME

# Create sparse image
# You should modify 1024g to the size of your maximum Time Machine backup size.
$ hdiutil create -fs HFS+J -size 1024g -type SPARSEBUNDLE -volname "Time Machine" $SBNAME
$ ls $SBNAME
Info.bckup    Info.plist    bands        token

Once this is done, copy sparse bundle directory into your network volume:

# mine network disk is called /Volume/tm
$ cp -R $SBNAME /Volumes/tm

Create a separate user for TimeMachine

It is a good practice to create a special user specifically for network drives that will be used for TimeMachine backup.

I called mine tm:

Apply hack with access rights

On MacOS X versions prior to 10.6.3, this step would be not necessary, but on latest versions TimeMachine automatically resizes your sparse bundle to occupy the whole space. We’ll deny it using access rights hack.

To be able to continue, you should access your NAS using root credentials.

# login to your NAS via ssh
$ ssh -i ~/.ssh/my.key root@nas
Warning: Permanently added 'nas,' (RSA) to the list of known hosts.
Last login: Wed Oct 17 19:35:37 2012 from amber

# go to the destination of your shared network volume
root@NAS:~$ cd /mnt/array1/tm/

# check out that sparse bundle has been successfully copied
root@NAS:/mnt/array1/tm$ ls -l
drwxrwsrwx    4 tm       hdusers      4096 Oct 17 19:08 amber_001122334455.sparsebundle/

The main idea behind access right hack is pretty simple: deny TimeMachine user from write access to specific files:

# Give read-only access for tm user
root@NAS:/mnt/array1/tm$ cd amber_001122334455.sparsebundle
root@NAS:/mnt/array1/tm/amber.sparsebundle$  chown root:root Info.*
root@NAS:/mnt/array1/tm/amber.sparsebundle$  chmod a+r-w Info.*

# Check access rights:

root@NAS:/mnt/array1/tm/amber.sparsebundle# ls -l
-r--r--r--    1 root     root          500 Oct  9 20:36 Info.bckup
-r--r--r--    1 root     root          500 Oct  9 20:36 Info.plist
drwxrwsrwx    3 tm       hdusers   1155072 Oct 17 19:08 bands/

Configure TimeMachine

The last step is to configure TimeMachine to backup to network disk. It’s the same process as with usual hdd.

Once TimeMachine is configured, let’s verify that it is backing up normally and will not occupy the whole disk space.

Open Spotlight and type Console — a special program to see your software logs. Matching string for TimeMachine will be backupd

At the console logs you should see something like this:

10/9/12 8:39:36.012 PM Starting standard backup
10/9/12 8:39:36.026 PM Attempting to mount network destination URL: afp://tm@NAS._afpovertcp._tcp.local/tm
10/9/12 8:39:36.480 PM Mounted network destination at mountpoint: /Volumes/tm-1 using URL: afp://tm@NAS._afpovertcp._tcp.local/tm
10/9/12 8:39:53.925 PM Resizing backup disk image from 1024.0 GB to 1834.2 GB
10/9/12 8:39:53.938 PM Could not resize backup disk image (DIHLResizeImage returned 35)
10/9/12 8:39:53.939 PM Renaming /Volumes/tm-1/amber_c82a141a607c.sparsebundle to /Volumes/tm-1/amber.sparsebundle
10/9/12 8:39:53.971 PM Running backup verification
10/9/12 8:40:57.454 PM Backup verification passed!
10/9/12 8:41:01.105 PM Disk image /Volumes/tm-1/amber.sparsebundle mounted at: /Volumes/Time Machine
10/9/12 8:41:01.113 PM Backing up to: /Volumes/Time Machine/Backups.backupdb
10/9/12 8:41:01.117 PM Ownership is disabled on the backup destination volume.  Enabling.
10/9/12 8:41:12.304 PM Backup content size: 95.2 GB excluded items size: 18.1 GB for volume sys
10/9/12 8:42:20.556 PM Backup content size: 668.6 GB excluded items size: 248.4 GB for volume storage
10/9/12 8:42:20.564 PM 596.84 GB required (including padding), 1023.05 GB available
10/9/12 8:42:20.616 PM Waiting for index to be ready (101)

The message we’re most interested in is Could not resize backup disk image (DIHLResizeImage returned 35), which means that our access rights hack worked and TimeMachine will be limited by 1024GB.

However, reporting will show you the whole disk size as available — don’t be confused by this:

Related info