Viraj's Weblog

This weekend I finally installed Leopard on my macs. I have an old Powerbook G4 15" and a Mac Mini. Both of them run it great (I have at least 1G RAM on each). At home I also have an Ubuntu server running on a laptop which I use for various Linux things. I've been sharing drives via Samba on it and hacked up my own backup scripts.

But with Leopard, there is this cool Time Machine thing I can use right? Well I wanted to use a network share via Samba with Time Machine. Turns out it is not so straightforward. OS X by default won't let you use the network drive. This post describes how to get around that. There is also a wealth of information here. Great, now I can select the network drive in Time Machine.

But now I was getting an error about creating the disk image. I watched a bit what it was actually trying to do on the Samba share and noticed that it was using the machine name in the filename being created, which is a 'sparsebundle' file. My machine name was something like 'Powerbook G4 15"' and I had a feeling the '"' or some other character in the filename was not playing well with Samba. So I changed my computer name (via Preferences -> Sharing) to some very simple name. Still no go .

After some searching I came across this post which seems to describe my problem. It generally suggests to create the disk image file manually and then copy it to the network share. But I wondered, why not try creating this directly on the network share? I should have the same problem Time Machine gave but perhaps I can get more information and debug further. So I tried it, but unfortunately the command given in the post was wrong. A few comments below describes the correct one (wtf don't they fix this?). Here is the command I ran:

hdiutil create -size 50g -fs HFS+J -type SPARSEBUNDLE -volname "Backup of powerbook" powerbook_000d93b43026.sparsebundle

And I got the unsexy error:

hdiutil: create failed - Operation not supported

Fooey. Ok, I didn't get much debug info there. It sounds like some operation is being tried on the Samba share, but what? Next I followed the rules and created this image on a local drive. That worked fine. Now the post states to copy this image over, but I instead tried to 'mv' it. This should try to replicate everything at the destination and perhaps give me more info. It did:

mv /tmp/powerbook_000d93b43026.sparsebundle .
mv: chown: ./powerbook_000d93b43026.sparsebundle/bands/62: Operation not supported
... lots more
mv: chown: ./powerbook_000d93b43026.sparsebundle: Operation not supported
mv: /bin/cp: terminated with 1 (non-zero) status: Cross-device link

Interesting! So it looks like the real culprit here is 'chown'. OS X is trying to chown these directories on the Samba drive, which of course is not supported. Looking at the files created by hdiutil, it looks like it is trying to chown the group 'wheel':

powerbook_000d93b43026.sparsebundle valankar$ ls -lRa|more
total 16
drwxr-xr-x@ 6 valankar wheel 204 May 24 10:27 .
drwxrwxrwt 10 root wheel 340 May 24 10:27 ..
-rw-r--r-- 1 valankar wheel 498 May 24 10:27 Info.bckup
-rw-r--r-- 1 valankar wheel 498 May 24 10:27 Info.plist
...

Whatever, knowing this is not helping me much. In fact, I just found another post where someone digged further. After copying it over (actually the 'mv' copied it just fine but bombed on the chowning), I enabled Time Machine and it generally worked. But it worked SLOW.

As an aside, I've generally had some slowness using Samba when it involves lots of intense disk access. Say I'm watching a video as well as recording something with EyeTV on the Samba share. It generally will clip the video pretty badly. No amount of Samba tuning on my part could improve this and I eventually gave up. But Time Machine was ridiculously slow, and it drove me to wonder, "WTF am I using Samba for anyway?" I mean seriously, I have no Windows boxes here. Why aren't I using Apple File Sharing? Surely Linux supports it right?

Thus began my journey into setting up netatalk (AFP) on Ubuntu. It was a short one and generally without hiccups. This page has some pretty good docs, however with Ubuntu there is one stickler. SSL support is not compiled into netatalk, and this is required for Leopard. The workaround is described here. Sheesh, why even include the package if it's essentially unusable? Well it works with Panther, albeit with a warning. But with Leopard you just get an error trying to connect.

Now how do I connect to my share? Well I have yet to figure out how to show my shares in Finder. Instead I have to go directly to Go -> Connect to server. In there I type the full path of the share, e.g.:

afp://system76/timemachine_powerbook

At this point I came across a problem. In my /etc/hosts file on the server I had something like:

127.0.1.1 system76 ...

And when I attempted to connect, it hung at trying to connect to 127.0.1.1. Evidently this IP is passed along over AFP. I fixed my /etc/hosts so my hostname was not pointing to a loopback (no idea why it was in the first place).

Voila, I have a network share now. Sadly, neither hdiutil nor Time Machine were able to create the disk image on the network drive, so I still needed to create the image locally and copy it over. But once I did it worked like a charm, and much faster than Samba. It's still pretty slow for the initial backup of about 20G (in fact I think it took like 12 hours), but after that it worked pretty well. I'm a bit worried how it will deal with large backups though, as it could be lots of traffic over the network.

Another thing I have to worry about is resizing the disk image. This post describes it somewhat, and it's likely I'll have to do that at some point.

I setup the same thing on my Mac Mini, so now I have 2 Time Machines going to the same share. Plus I have AFP setup and no more need for Samba. Good riddance!

One caveat. My syslogs are filling with:

May 26 09:02:33 system76 afpd[3651]: bad function 4F
May 26 09:03:05 system76 last message repeated 89 times
May 26 09:03:25 system76 last message repeated 163 times

Turns out this is some undocumented AFP call.

Update: And now I think I've lost faith in Time Machine network backups altogether. There is a great post describing the pitfalls of such a solution. Maybe it's time to move back to rsync snapshot backups.