Problems mounting a Debian drive over AFP

It took me ages to find the answer to this, so I figured I’d post the answer for posterity; hopefully between us, Google and I can help the next person avoid that hassle.

I’ve created a Debian virtual server in Parallels for some development work. To ease the pain of mounting drives, I’ve configured AFP (Apple File Protocol) on the server. (As a sidenote: there’s some issues with Debian’s AFP package, netatalk, and OS X Leopard which mean you have to recompile netatalk, for which you can find instructions here. You probably also want to have your server auto-discovered and appearing in the “Shared” areas of the finder, for which you can find instructions there. Some Debian chutzpah will be required to follow both these sets of instructions.)

All was running well, and I was happy, until one day the drives stopped mounting…

After a brief period of clicking, moaning and despair, I dug around in the server and found that the Debian syslog contained the following spatter:

Apr  4 19:21:12 vmachine1 afpd[2236]: ASIP session:548(5) from 192.168.0.11:50642(7)
Apr  4 19:21:12 vmachine1 afpd[2177]: server_child[1] 2235 exited 1
Apr  4 19:21:12 vmachine1 afpd[2177]: server_child[1] 2236 done
Apr  4 19:21:12 vmachine1 afpd[2237]: ASIP session:548(5) from 192.168.0.11:50643(7)
Apr  4 19:21:12 vmachine1 afpd[2237]: dhx login: simon
Apr  4 19:21:12 vmachine1 afpd[2237]: uams_dhx_pam.c :PAM: PAM Success
Apr  4 19:21:12 vmachine1 afpd[2237]: uams_dhx_pam.c :PAM: PAM Auth OK!
Apr  4 19:21:12 vmachine1 afpd[2237]: login simon (uid 1000, gid 1000) AFP3.1
Apr  4 19:21:12 vmachine1 afpd[2237]: Warning: No CNID scheme for volume /home/simon. Using default.
Apr  4 19:21:12 vmachine1 afpd[2237]: Setting uid/gid to 1000/1000
Apr  4 19:21:12 vmachine1 afpd[2237]: CNID DB initialized using Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)

The issue seems to be that the CNID database for the share /home/simon got corrupted somehow. In my case I was able to blitz /home/simon/.AppleDB and wander off whistling a happy tune. I believe that there may be an issue with losing aliases you’ve created in the Volume with the blitzing approach and I’ve read of other people using DB recovery tools (specifically the command db_recover), your mileage may vary.

Hope this helps someone. If you think I’m wrong headed, ignorant and foolish, please chime in with a comment…

Join the Conversation

5 Comments

  1. I would like to add that afpd adds a .AppleDB to ALL shares. In my case, I had a few shares that had corrupted .AppleDB’s so I had to rm all of them not just my ~/ share. Also one should stop Netatalk before killing the DBs.

    Works like a charm when you get all of the .AppleDB’s. Thanks!

Leave a comment

Leave a Reply to Drew Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.