Netatalk is an Open Source 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 compliant file-server leads to significantly higher transmissions speeds for older Macs compared with 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 Mac OS and Mac OS X / macOS clients).
Netatalk v3 supports Mac OS X / macOS style filesystem metadata, while providing seamless interoperability with Samba. It is compliant with AFP 3.4, which was the final revision of the protocol, and supports Spotlight in version 3.1 and later.
However, it is less useful for Classic Mac OS or Apple II clients, because AppleTalk support was removed, and with it the ability to connect with AFP 2.1 clients or earlier.
See also the release notes for Netatalk 3.0.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 Mac OS 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 persistent 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.
See also the release notes for Netatalk 2.0.0.
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 Netatalk issue tracker whether it's a known bug that is already being worked on.
If that doesn't help, consider asking at the Netatalk mailing lists or an online forum whether others might have an idea what's going on.
Before asking, 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 issue tracker.
In case, the developers want you to provide more details about crashing processes, have a look at Using GDB to Analyze a Crash.
In the vast majority of scenarios, use dbd.
The last backend is only suitable for sharing HFS CD-ROMs directly
with Netatalk. Avoid if at all possible as this backend can lead to
duplicate IDs which can cause data loss!
The mysql backend is useful for very large deployments with hundreds of
thousands or millions of files shared, where performance and reliability
is of utmost importance. The drawback is that you have to configure
and operate a separate MySQL database instance by yourself.
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.)
- Choose a CNID backend, in general this means "dbd" (see the chapter about CNID backends in the manual)
- Finally add an entry in your configuration file and connect from a Mac to the volume, to see if things work.
It depends. While Netatalk 3.x integrates almost flawlessly with Samba, there are a couple of problems when using Netatalk 2.x and earlier:
- Filename/foldername encoding: By default both Netatalk 2.x 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 (Netatalk v2 only.) 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.
What are the .AppleDouble and .AppleDB? directories and .Parent files which are created in the Netatalk Shares?
These are described at the Special Files and Folders page.
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.
Starting with Netatalk 2.1 there's a dedicated and versatile utility exactly for this purpose: dbd.
Ah, good question! The unenlightened often mispronounce this word 'net-'a-to.k. The correct pronunciation is 'ned-*-to.k\ (the 't' is soft, like d, and the first 'a' is a schwa).
The Netatalk logo depicts a stylized BSD Daemon on top of an AppleShare serving tray, hooked up to a daisy-chained LocalTalk network.
| Logo | Description |
|---|---|
 |
Its first appearance was as a custom AppleShare volume icon, encoded in the project's source code since at least 1994 (version 1.3). |
 |
In the early 2000s, a colorized version of the Netatalk Daemon was featured on the UMich project website. |
 |
The present design was introduced in 2005 in the documentation for Netatalk 2.0, where the Daemon has been reduced to a silhouette, overlaid with twisted network cables. |