As of Ubuntu 9.04 (aka Jaunty Jackelope), it is no longer necessary to jump through hoops to access files on an Ubuntu (or Debian) server from a Macintosh OS X client via netatalk. Unfortunately, if you’ve previously gone to the trouble of jumping through those hoops by doing a custom compile of netatalk with openssl support , you are likely to run in to problems once you upgrade to Jaunty (and probably the soon to be released v9.10, aka Karmic Koala). Fortunately, the fixes are pretty easy if you’ve managed to find this blog post.
There are two issues. First, in order to support encrypted login, the custom build and configuration of netatalk loads some custom user authentication managers (‘uams’) that aren’t present in the latest packaged version of netatalk. The /etc/netatalk/afpd.conf file probably ends with a line like this:
- -transall -uamlist uams_randnum.so,uams_dhx.so -nosavepassword -advertise_ssh
This both produces failures when trying to load the nonexistent modules, it also means the default modules fail to load, including a new, prebuilt, module ‘uams_dhx2.so’ which supports encrypted authentication on Mac OS X 10.4 and later. The simplest solution is to edit /etc/netatalk/afpd.conf to either remove or comment out that line and just use the defaults. Once you’ve updated the config, restart netatalk with the following command ‘sudo /etc/init.d/netatalk restart’.
The next problem is that the newer versions of netatalk use a newer version of a simple database library to store Apple-specific file information. They provide a script for updating the db files, but you probably don’t know to look for it to run it manually. For details, check the README.debian for the netatalk package, which is most likely found in ‘/usr/share/doc/netatalk/README.debian’.
This version of Netatalk use to Berkeley DB 4.7.
Earlier releases used Berkeley DB 4.2. As Netatalk does not
automatically update its database, you may experience problems like
those described in bug #200373: no files showing up in your folders.
If you have such problems, you may try to upgrade the database using the
Before you run the script, run ls -la on the target directory and pay attention to the user and group ownership on the .AppleDB directory because after running the script, it tells you to check the permissions/owernership on the files it updated, and it is really good to know what the correct permissions were.