Why AFP is better than SMB.

With netatalk, I can serve AppleShare Filing Protocol shares from my Ubuntu box. Since this is where all of my media files are stored, this is kind of nice. So, why use AFP over SMB (or NFS, for that matter)? Well, I still haven’t been able to get NFS shares to work properly from my MacBook Pro. It just sits there Connecting to nfs://poul … forever. So NFS is out. (I have configured the shares under Ubuntu, or at least, I think I have. I did use the GUI tool, which as you’ll read below, didn’t fully set up the shares for SMB either…) As I mentioned in a previous post, if you use the GUI tool to set up Samba (SMB) shares, you also need to use the smbpasswd -a [username] command. Finder doesn’t handle Samba shares very well. It takes an age to connect to them, and if they disconnect (ie, the network disconnects, such as when you move from one location to another, and change WiFi network; or the server restarts) you get a long Finder hang while it looks for the connection. OS X also used to disconnect Samba shares when you went to sleep, or if you slept for a long time. (This may have been the server, I don’t know) I can reconnect to an AFS share almost immediately. This means I can wake my MacBook Pro from sleep, wait a few seconds while it reconnects to the Airport network, and then press play on iTunes. All of my music lives on an AFP share, but it started playing immediately. It is little things like this that make computing nice again.

tail -f /var/log/syslog is your friend

I’ve just spent about three hours troubleshooting encrypted passwords for netatalk. Basically, the plain netatalk that comes with Ubuntu, due to licensing reasons, does not include SSL support, which means only plaintext password authentication is supported. That wouldn’t be too bad for my purposes (I’m running on a secure network), but OS X complains each time you try to connect using plaintext only passwords. So, I followed the instructions from coderspiel: A year of plaintext AFP passwords is enough, but it wouldn’t work. Firstly, it needs BerkelyDB 4+, but will uninstall this to install 3+, which the package manager thinks it needs. Stupid. Secondly, some bits and pieces won’t compile. I did do some editing, but I felt this may break the whole thing, so I didn’t want to install the whole lot, just the missing uams. Basically, uams_dhx.so was missing. So, I built this, and others, and installed them. Still no joy. I did kind of get uams_randomnum.so or something to work, but it kept saying incorrect password. Then, I stumbled on the idea to use tail -f /var/lov/syslog. This immediately showed me I was missing the symlink from uams_dhx_passwd.so to uams_dhx.so So that’s all there was to it. Now connections work perfectly. And AFP connections seem to be a bit more robustly handled (ie, less spinning beachballs of death), and faster for things like iTunes.

Weirdest netatalk bug ever

Okay, this one has me stumped.

I have all of my iTunes music stored on a local server, along with the remainder of my media files (Movies, TV series, copies of Digital Photos). This has been working pretty seamlessly, until I noticed something odd.

I knew I had some files there, but they weren’t displaying. Logging into the server using ssh, or for that matter SMB showed me the files were indeed there. But whenever I logged into the server via AFP, they don’t.

Most files do, but some of them aren’t there. But if I access the share using a parent share (/home/media, instead of /home/media/music), then the files are visible again.

I am at my wits end here!

Don't forget to smbpasswd -a [username]

Aargh! I’ve just spent ages troubleshooting SMB networking on Ubuntu, only to realise that there weren’t any SMB users - which is crazy. Why not just default to having the local users match up with the SMB users. After finally getting that working, I did also get AFP sharing working. Which does appear to just use the users. Still, I need to keep SMB going, for the Windows/Xbox machines that sometimes visit my network…