If you’ve recently upgraded to Leopard, you might have started running into problems accessing AFP shares on Debian if you’re using netatalk with the cleartext UAM (uams_clrtxt.so).

Trying to connect to the shares results in the error

There was an error connecting to the server. Check the server name or IP address and try again.

It’s not a very helpful error, but if you do some digging, you’ll find out it’s Finder error code 5002, ‘afpBadUAM.’

It was at this point that I remembered that Debian’s netatalk doesn’t include any SSL-related authentication modules because of a licensing incompatibility (see Debian bug #191790). At the time, I wasn’t in the mood to dig into building the package manually, so I used the cleartext UAM — we’re on a secured closed network, and, though Tiger warns about sending a cleartext password every time you connected to a share, it’s more than happy to let you do so. There’s even an option to turn the warnings off.

This behavior has apparently been changed in Leopard — it appears to outrightly refuse to send cleartext passwords. This is probably a good idea, but it means you now have to build netatalk to include the DHX UAM that it doesn’t include by default.

I found two posts by Damon Timm and Durk Hellinga that describe the general process. However, as my comment on Durk’s blog says, I had some problems with circular dependencies. When you try to build the package with dpkg-buildpackage, it complains

% DEB_BUILD_OPTIONS=ssl dpkg-buildpackage
dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.6) debhelper (>= 4.1.46) dh-buildinfo d-shlibs (>> 0.19) libdb4.2-dev libwrap0-dev libpam0g-dev libslp-dev libcupsys2-dev heimdal-dev (>= 0.7.1-3)
debuild: fatal error at line 993:
You do not appear to have all build dependencies properly met, aborting.
(Use -d flag to override.)
If you have the pbuilder package installed you can run
/usr/lib/pbuilder/pbuilder-satisfydepends as root to install the
required packages, or you can do it manually using dpkg or apt using
the error messages just above this message.

Unfortunately, libcupsys2-dev and libkrb5-dev seem to be mutually incompatible with heimdal-dev — aptitude won’t install both at the same time. I tried installing each by themselves and forcing dpkg-buildpackage to build with the -d switch, but /usr/lib/netatalk/uams_dhx.so still wouldn’t show up.

As it turns out, I wasn’t looking at the build output carefully enough. This post mentions to look for the line ‘Configure summary’, and for me it didn’t list the DHX UAM as being built. Looking at the output from the configure script, I realized I didn’t have libssl-dev installed. After installing that, everything went smoothly.

Relatedly, Yvo van Doorn describes how to get your Linux-based AFP server to show up correctly in Leopard’s new Finder. Was Glück! I knew there had to be a Zeroconf daemon for Debian, but I had no idea what it was called, or how to make it work if I did. However, I think the XML configuration for Avahi that Yvo has in his post is suffering from some formatting problems. Here’s my version:

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" standalone=‘no’?><!–*-nxml-*–>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
  <name>%u</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>
</service-group>

Documentation for Avahi’s service configuration files

Usability Improvements to Interaction with Network Shares in Leopard

The frustrating and limiting way in which Finder forced you to access network shares in Tiger has long been a sore point with me. First you had to trawl through Network and its mess of ugly workgroup folders and iconless symlinks. Then you had to click ‘Connect’, wait for the authentication dialog to come up, enter the same authentication information every time, and then click ‘Connect’ again. Then you had to select a single share, and repeat the entire process if you wanted to work with multiple ones. And then, heaven help you if one of the connected shares subsequently becomes unavailable. If I was on my MacBook Pro, accessing a share on my Powermac or file server, and then left the house with the MBP, the entire operating system would be brought to a halt for minutes when the MBP was woken up, while Finder spins looking for the lost share. From a usability standpoint, it was completely awful.

The Finder in Leopard has completely solved all those problems. When shares become unavailable, the system doesn’t beachball — Finder just quietly and patiently keeps looking for the share while everything else remains responsive. Tiger left me wishing for an analog to Windows’ ability for network drives to reconnect at login. But the way Leopard has been redesigned to just reconnect to network shares automatically on demand (using the last username you used) beats mapped network drives hands down. It pleases me that Apple completely rethought the problem and introduced a far better solution.

These things all couple to allow me to work with network shares completely transparently, the way I want to. I can drag locations in network shares into the sidebar, and clicking them automatically connects to the share if unconnected. If the share is unavailable, the system doesn’t freeze looking for it. And it’s so great to be able to have our file server show up in Finder’s sidebar now! No more wading to find shares you don’t access regularly — they are instantly accessible. Bravo!

Share This