Netatalk and AFP problems

Hi,

I'm having some issues with Netatalk and AFP lately. Users complain about slow performance and weird things happen to files. Like filenames that suddenly change to some random garbage (1).

According to this guy, upgrading to Netatalk-3 greatly improved performance. So that's what I did. I finally bit the bullet and upgraded Netatalk-2.x to Netatalk3-3.1.8.

That seemed to work fine, but resulted in other problems and errors. Which in turn resulted in more complaints. So, I did more digging and discovered that the system is littered with lots and lots of Orphaned AppleDoubles, Bad AppleDoubles and corrupt AppleDoubles.

Code:
Bad AppleDouble "/Path/To/.__SomeFile.psd"
{ad_open.c:547} (warn:ad): ad_valid_header_osx("/Path/To/.__AnotherFile.psd"): not an adouble:osx file

I got rid of most of these, by running dbd -r and dbd -rf. But when I ran dbd -s, to see if things are fine, I still get lots of Bad AppleDoubles.

So, my first question is: Is it safe to just remove these Bad AppleDoubles? Right now they seem to do more harm than good. So I figured deleting them would be the obvious action. But I'm nog sure about the consequences.

And my second question is: What is the best course of action to run and maintain a fileserver, running Netatalk and lots of Macs? (Well, lots is a bit of a stretch. About 15 Macs). I've been doing some research on AFP and it's a.... weird... protocol. I mean, keeping a database with CNID's? What is that all about? And storing all this metadata in hidden dot-underscore files? How do I make sure things keep running smooth? How do I prevent getting these Bad AppleDoubles? And where did they get bad in the first place?

(1) Apparently this was caused by some people mounting shares as SMB, while others had them mounted as AFP. But still wierd that it happened.

Thanks in advance! :)
 
I would just switch to net/samba43, you won't miss anything crucial by using SMB/CIFS instead of Apple's AFP. The only working server implementation for AFP is really the Apple's own one, sadly.
 
Just write access isn't enough. It requires exclusive write access. All file system modifications even just metadata operations like renaming have to go through netatalk for it to keep its metadata in sync. An other problem in your case is that Samba mangles filenames illegal under the SMB protocol. In theory Samba 4.3 includes a VFS module named vfs_fruit to integrate Samba with netatalk and implement the APPL SMB extension. This SMB extension should also eliminate the need for AFP unless you're stuck with very old OS X versions. Without said protocol extension the OS X SMB performance sucks even in a LAN, because the stupid Finder will perform O(n) roundtrips per directory listing where n is the number of directory members before it displays the directory content.
 
Well, exclusive write access for Netatalk alone is simply not an option.

I'm going to look into getting the Macs on SMB, so I can ditch Netatalk and AFP altogether. Any advice in that regard?
 
Cut your throat now to shorten the suffering?

Sorry that wasn't very helpful. I tried to get Samba 4.3 on FreeBSD 10.2 to play nice with Mac OS X 10.11 and failed unless you consider up to 10 seconds an acceptable response time to display a folder containing a few hundert files.
 
Back
Top