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
001122334455

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

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

The message we’re most interested in is com.apple.backupd: 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

• Time Machine Setup: How to prevent disk image from resizing
• Time machine on a network drive
• TimeMachine doesn’t play well with custom sparsebundles
• Root access on Buffalo LS-WXL
• Buffalo LS-WXL linkstation duo
• Network attached storage