What is Netatalk for? What can I do with it?
Netatalk is an OpenSource software package, that can be used to turn an inexpensive *NIX machine into an extremely performant and reliable file and print server for Macintosh computers.
Using Netatalk's AFP 3.1 compliant file-server leads to significantly higher transmissions speeds compared with Macs accessing a server via SaMBa/NFS while providing clients with the best user experience (full support for Macintosh metadata, flawlessly supporting mixed environments of classic MacOS and MacOS X clients).
Due to Netatalk speaking AppleTalk, the print-server task can provide printing clients with full AppleTalk support as well as the server itself with printing capabilities for AppleTalk-only printers. Starting with version 2.0, Netatalk seamlessly interacts with CUPS on the server
After all, Netatalk can be used to act as an AppleTalk router, providing both segmentation and zone names in Macintosh networks.
I use an older Netatalk version. Should I upgrade to 2.0?
Let's have a look at what has changed compared to 1.6.4:
- Netatalk's file server, afpd, now speaking AFP 3.1 allows long filenames, UTF-8 names, large file support and full MacOS X compatibility
- The print server task, papd, can directly interact with CUPS, automagically sharing all CUPS queues
- Kerberos V support, allowing true "Single Sign On"
- Whole rework of the CNID subsystem, providing reliable and persistant storage of file and directory IDs
- Huge improvements regarding product documentation making Netatalk's features accessible more easily
- Tons of bugs fixed compared to all previous versions
To make a long story short, everyone not using symlinks inside Netatalk shares (this violation of AFP specs is not supported any longer) and willing to complete the sometimes extensive upgrade process should switch to 2.0. But be sure to read carefully the chapter about upgrading in the docs first.
I think, I found a bug in netatalk. Where should I report it?
First of all, try to isolate the problem and see whether it's not a feature instead (some of the underlying mac-related basics like file/folder IDs and the like, look irritating for people newly entering the world of cross-platform networking)
Then have a look in the archives of both netatalk-admins and netatalk-devel list whether it's a known bug, already being worked on, or something special.
If that doesn't help, consider asking the lists whether some others might have an idea what's going on (try to avoid using the SourceForge discussion forums since most experienced users and developers only monitor the mailing lists).
Before asking the list, try to understand and accept the basic principles for reporting bugs and asking for help If you're finally sure you found a bug, then please report it at the SF Bugs section and post it to the netatalk-devel list as well.
In case, the developers want you to provide more details about crashing processes, have a look at How to use gdb.
Which CNID scheme should I choose for my volumes?
"dbd". Only in the case user homes you could consider using "cdb" instead. You can switch between those 2 CNID backends without any hassles if afpd isn't running while you're changing the backend definition in your AppleVolumes.default file.
The "last" backend is only suitable for sharing HFS CD-ROMs directly with netatalk. Avoid at all if possible as this backend can lead to duplicate IDs which can cause data loss!
Compare with the relevant chapter in the docs. 
Always follow these steps unless you know exactly what you do:
- Create the sharepoint on the Unix side with appropriate permissions. This means setting the SGID bit as well, so the old AppleShare semantics (always treating files/folders with the permissions that apply to the surrounding folder) will work flawlessly. So do not use chmod 775 but chmod 2775 instead.
- Then decide which volume charset to use (it is strongly recommended to use the default UTF8 volcharset but in some special cases it might make sense to use another encoding like ISO-8859-15, instead. Have a look at the volcharset option)
- Choose a CNID backend, in general this means "dbd" (see the chapter about CNID backends in the manual)
- Finally add an entry in your AppleVolumes file and connect from a mac to the volume, to see if things work.
How does Netatalk integrate with Samba?
It depends. There are a couple of problems:
- Filename/foldername encoding: By default both Netatalk 2.0 and Samba 3.0 use UTF-8 precomposed on the server side. So at a first look, this problem is solved.
- "Illegal" names, that make Windows choke, are still a problem. There exists an AppleVolumes option called "mswindows", which will prevent Mac clients from saving such names. But this leads to Netatalk's afpd breaking the AFP specifications and is no real solution (like a working Samba VFS module, that mangles such names on demand in a sane way, would be). Additionally, this option breaks saving to Netatalk volumes for several applications, i.e. OfficeX.
- Hiding the metadata stuff from the other platform: You might want to hide all the directories and files described in the Special Files and Folders entry by using Samba's veto option. You can do the same for Mac clients too using Netatalk's veto option. For samba:
veto files = /:2eFBCLockFolder/.FBCLockFolder/:2eFBCIndex/.FBCIndex/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/\ Network Trash Folder/.AppleDB/:2eVolumeIcon.icns/.VolumeIcon.icns/Icon/.AppleDouble/.AppleDesktop/desktop.ini/RECYCLER/ delete veto files = Yes
- File locking: partially working as Netatalk is using POSIX locks and SAMBA uses them too. But SAMBA usually also uses oplocks which should be disabled for interoperating with Netatalk. More importantly, open modes are not synchronized. Thus Samba will now nothing of a deny read/write open AFP mode from an AFP client and vice versa.
These are described at the Special Files and Folders page.
Why can't I mount more than one server?
When trying to mount multiple independent servers running Netatalk, you might run into a problem where the workstation thinks that the second server is the same as the first one that was mounted. This problem is often due to what the /etc/hosts file looks like.
"Out of the box", /etc/hosts often looks like:
127.0.0.1 localhost.localdomain localhost <some ip addr> hostname.domainname hostname
Netatalk will look at the first line to find out what server it's running on. If both servers you're trying to mount have identical first lines in /etc/hosts, Netatalk will think it's trying to access the first server you mounted.
The solution, in my hands and as suggested by several members of the Netatalk mailing list, is to change the order of entries in /etc/hosts. In the example given above, this could be done simply by changing it to:
<some ip addr> hostname.domainname hostname 127.0.0.1 localhost.localdomain localhost
That is, reversing the order.
How can I check the consistency of the CNID databases?
Starting with Netatalk 2.1 there's a dedicated and versatile utility exactly for this purpose: dbd.