Netatalk seems to always have some issue with OS X. Why I still use little NAS boxes for this that and the other is beyond me. I got stuck dealing with this for a little while and if you’re using Netatalk w/ a DHCAST128 UAM you probably will too. For more on DHCAST see the Netatalk page on UAM support. Kerberos and DHX2 are arguably better, but I’ve found they don’t always work right on some of my NAS boxes.
This wasn’t just a quick defaults command as it was in previous instances. It’s not much of a script but the following should fix it if you’re having this issue like I was.
/usr/bin/defaults write /Library/Preferences/com.apple.AppleShareClient afp_host_prefs_version -int 1
/bin/sleep 60
/usr/bin/defaults write /Library/Preferences/com.apple.AppleShareClient afp_disabled_uams -array “Cleartxt Passwrd” “MS2.0″ “2-Way Randnum exchange”
I had to reboot on one of my machines after this but on the others I didn’t. Hope it helps someone else…
And if you want to go back to the way things were before, simply remove com.AppleShareClient.plist from /Library/Preferences (w/ sudo):
rm /Library/Preferences/com.apple.AppleShareClient.plist

NAS (Network Attached Storage) devices are a popular alternative to providing centralized file services to smaller environments. This includes devices such as the Seagate BlackArmor, the DroboShare NAS and the Netgear ReadyNAS Pro. These are inexpensive as compared to an actual server, they require less management and they often come with some pretty compelling features. But one of the primary reasons to buy a NAS can end up being a potential pain point as well: they require less management than a server because they can’t do as much as a server can.
For example, the option to replicate between two of them. Most have NAS to NAS replication built in. However, that replication ends up being dependent on having two of them. But what if you just have a machine on the other side of the replication, want to back it up remotely compressed or want to back up to a cloud environment. Well, if it’s not the same daemon then you’re typically stuck with CIFS, NFS, HTTPS (WebDAV) or FTP. The devices don’t typically give you the option to push directly from it nor to run a daemon that non-proprietary device can connect to directly, so you’d have to use a client to do the offsite sync. One example of how to do this would be to use JungleDisk and an Amazon S3 account. JungleDisk would mount the AmazonS3 storage and the NAS storage (all share points). You would then use a tool such as ChronoSync, Retrospect (Duplicate scripts not backup scripts btw) or even rsync to backup the device over CIFS. It’s not pretty, it’s extra latency and management, but it would work.
The reason you would do synchronization is that if you attempt to backup (a la Retrospect Backup Scripts) then you’d send big, monolithic files over the wire. The smaller increments of data you can send over the wire the better. Another tool that can do that type of sync is File Replication Pro. That would actually do blocks instead of files, pushing an even smaller increment of data over the wire. There are certainly other services. You could even open up the firewall (for just the specific ports/IP addresses requiring connectivity, which is always a potential security risk) and have a remote backup service come in and pull the data sync over FTP, CIFS or WebDAV (if you want to stick with a cloud backup solution), but those types of services are a bit more difficult to find.
The same is pretty much the same for cloud based storage. With the exception that instead of a built-in feature you’re either looking for a built-in feature or an API that allows you to develop your own. The moral of this story, if you use a NAS or a cloud-based solution and you want to back your data up, then your options are limited. Keep this in mind when you decide to purchase a NAS rather than, let’s say, a Mac OS X Server running on a Mac Mini with some Direct Attached Storage (DAS) connected to it.