The upgrade to Snow Leopard breaks 10.5.x Time Machine backups configured with AFP shares on network volumes, as per this older hint, for example.

After some trial and error, I was able to find out that the secrect lies with a hidden property list file that specifies the hardware UUID for the machine to be backed up. The following are some simple instructions to set up a new backup volume from scratch. They may work for upgrading a Leopard Time Machine disk to Snow Leopard, but I have not been able to verify this.

Setup: If your Time Machine is already configured to back up to a networked AFP share, move on to the next step. Otherwise, follow the setup procedure in the above-linked hint.

Create a disk image named the same as your machine's computer name (not sure that this is crucial; you can find it in System Preferences » Sharing). This example is for a 500GB (max size) image for a machine named snowy:

Create a new text file, and copy and paste the below code. inserting your machine's hardware UUID in the noted spot -- you can find your hardware UUID in System Profiler. Save the file on your Desktop as com.apple.TimeMachine.MachineID.plist.

The title on this should be changed to "Non-Mac" networked volumes as mentioned in the original hint. I am successfully continuing to backup a couple of macbooks to an external disk on an imac with no changes needed.

Non-Apple AFP can be dangerous with time machine...
Authored by: dbs on Sep 24, '09 11:58:57PM

Everyone should be aware that using Time Machine on a Non-Apple AFP volume via these hints may put their backup data at risk. Here's why:

The technical reason why Apple limits Time Machine to 10.5+ AFP volumes appears to be to prevent disk image corruption. There were additional features added to AFP in 10.5 to support Time Machine. These presumably allow the disk image engine to force disk image journal data to write out all the way to the disk. Without such features, a network interruption can result in a corrupted filesystem on the disk image despite journaling. Remember, journaling relies on the journal being written all the way to disk before the changes take place. If you can't guarantee that (e.g., because of network/NAS buffering) then the journal is useless. Time Machine appears to rely heavily on disk journaling to deal with network drop-outs, interrupted backups, and the like. Take this away and your data is at risk.

If the NAS you are using supports these features it should report them to the OS and you should natively be able to choose that volume. If you have to trick the OS to use the volume it means the NAS does not support it.

To summarize: if you care about your backup data you should avoid using non-natively supported AFP servers.

(There is a less-than-satisfactory work-around: backup to a Mac, then use rsync to copy the disk image to the NAS manually. This is what I do to have an off-site copy of my backup.)

Non-Apple AFP can be dangerous with time machine...
Authored by: sunkid on Sep 25, '09 09:47:15AM

Thanks for the caveats! Can you clarify whether a network interruption would lead to a corrupted disk image or just to a corrupted backup?

There is also another issue users should be aware of that has to do with the size of the disk containing your backup image.

That said, I have a couple of backups to non-OSX based AFP shares running successfully now for about a year and I have not yet had any problems. One of these is from a laptop over WiFi with many of the backups interrupted due to the laptop being put to sleep.

That's interesting! What linux distro and AFP version are you using? Do you see any AFP related error messages in the system log? (I get a lot of '4F'-related errors, but they were there before as well)

I'm running OSX 10.6 and trying to get Time Machine to back up to a fileserver running Debian Lenny with netatalk and avahi. The target Debian filesystem is HFS+ and was created with the mkfs.hfsplus command from the hfsprogs package. Netatalk was patched using this trick:
http://blog.damontimm.com/how-to-install-netatalk-afp-on-ubuntu-with-encrypted-authentication/

I followed the instructions in the current hint for creating a sparsebundle with the .com.apple.TimeMachine.imacml.plist file as specified. It still doesn't work.

The backup volume shows up in the finder and can be mounted. I can copy files from the Mac to the Debian fileserver. However, Time Machine fails with an error 45. On the Debian side, the syslog shows afpd errors 4F and 4C.

Running 10.6.3 and my TM Volume is a Buffalo NAS which "supports TM" but probably not 10.6.3 though I need to look into firmware patches. In any case my backups appear to be working despite my not doing this change. However I'm seeing the following in the logs which I'm assuming is BAD. But all in all TM actually seems to work better with my Buffalo since 10.6.3.

I have since found that the latest versions of HFS+ support these added features. And they are just now being developed for netatalk (found in many NAS products). In the mean time I don't know the implication of NOT having these features but TM backups appear to continue to work. One might assume locking has to do with the ability to do multiple TM backups to a single destination. Possibly at the same time?

And BTW my 10.6.3 TM backups to my Buffalo Linkstation Live were working fine without the plist but I have added it to the sparsebundle now anyway. It was critical in my case to have the MAC address of en0 part of the sparsebundle name. At least that was the case with 10.5.8. Perhaps because I had that naming right is why 10.6 kept on working. The name convention is actually:

This didn't work for me initially, and I believe it was because TextEdit does not save the file as 'plain text', instead, as a rich text file which although can be renamed as a plist, doesn't contain the correct formatting.

So, if you too are experiencing this problem then try the following:

1) At the terminal type "nano com.apple.TimeMachine.MachineID.plist"
2) Paste in the XML file and replace the UUID as described
3) Press ctrl+O to write the file to disk
4) Press Return to confirm the write
5) Press ctrl+x to exit nano

I have to say i am a very beginner in programming languages and coding and these kind of things, however, i am quiet keen to
find a solution for limiting the backup size of TM on a disk image. Following your instructions I have created a sparsebundle dmg, using this command:

and this seems worked. Although i got stuck at step 2. I copied the code listed and if i am not mistaken, I was supposed to copy
it to a plist editor, which i quickly downloaded (TextWrangler) and saved it as com.apple.TimeMachine.MachineID.plist.

In the code i used my mac's UUID, which I believe to be "43059B79-1B9F-5CA0-AAB4-53D0CC605B0C" and saved it to the desktop.

Now, step 3 is to copy the file into disk image directory, which i think i did. I copied it to the external hard drive next to the dmg file.
But i am really not sure if this was correct cause nothing happened. TM still does not recognise sparsebundle as backup destination,
so i never really got to step 4.

Just to be clear, i have an imac (2008) and a GTA 1.5TB USB external hard drive meant to be for backup purposes. Obviously, I ended up reading
your post because i am running snow leopard and the famous command to reveal unsupported volumes for TM does not work anymore.

I would very much appreciate if you could help me out with some solutions to this problem.

Great article. Though this answer can be found elsewhere, I figured it would be best to include it in this articles comments as well.

If your remote file server is running Tiger 10.4, or Leopard < 10.5.6 you will run into problems with this solution due to the AFP protocol. You will need to enable Window/SMB sharing on the networked Time Machine server.

Unmount all afp connections to the server, and then mount via smb://x.x.x.x -- once connected, add that disk in Time Machine, and enter your credentials. Follow the rest of the steps in the article, and backups should work.

1. Create an AFP share on an OS X machine (set permissions, user accounts & passwords as you like)
2. Run `touch .com.apple.timemachine.supported` from Terminal.app on that share
3. Mount the AFP share by clicking around in Finder
4. Point Time Machine to the disk

It then goes off to create a .sparsebundle, mounts that and does a backup.

I may have run the magic `defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1` way back when, so you may have to run that too.

Both machines run 10.6.6, but I (maybe miss-)remember doing it like that on Leopard too.

(Before anyone says this doesn't work anymore, I'm doing an initial backup using that method right now)

10.6.7: Set up encrypted Backup in Time Machine for FileVault
Authored by: langiter on Apr 06, '11 06:08:00AM

My thanks to sunkid and many others! Thanks to you I now have a very neat solution for my Time Machine backups.

I use FileVault, almost never log out, and wanted an encrypted backup, and now it all works nearly seamlessly. I needed to use sunkid's manual method posted here, with the addition of the "-encrypted" flag in the "hdiutil create" command, but did it all for a locally attached hard drive. I stored the password for the encrypted disk image in my login keychain (so it's still secure) and wrote an AppleScript that mounts the disk image and runs a time machine backup. I scheduled this script to run every hour.

10.6: Set up Time Machine on networked AFP volume
Authored by: zwiri on May 14, '11 01:42:31AM

I want to use a part of my Excito B3 as Time Machine disk, however I don`t succeed in limiting the sparsebundle size. I'm running OS X 10.6.7 and it always tries to reset the size to the complete disk. If I make the Info.plist in the spareimage read-only, the Time Machine process crashes:

Thanks much, I used this hint (plus neilneil2000's advice to make the .plist with Terminal's nano) to make a Time Machine sparsebundle on a directly connected USB drive.

Having the sparsebundle makes it much easier to clone and manipulate Time Machine backups to other drives later.

Snow Leo had made it more difficult for me to do this easily. The main downside is that Snow Leo does not honor the gigabyte size cap you establish in the hdiutil step and appears to allow the sparsebundle to use up as much of the hard drive as it wants. This means you can't limit the sparsebundle to a portion of the drive without partitioning it ahead of time. Eventually your Time Machine will grow to fill all available space although, depending on your drive size, this might not be for quite some time.

Leopard made it easy to ensure that only a portion of a hard drive was used for a Time Machine sparsebundle but no longer.