-
Notifications
You must be signed in to change notification settings - Fork 96
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 has the best support for Mac OS X / macOS, and seamless interoperability with Samba. It is AFP 3.4 (the final version of the spec) compliant, and supports Spotlight and macOS style EA metadata. However, it is less useful for Classic Mac OS or Apple II clients.
Netatalk v2 on the other hand speaks AppleTalk, the legacy Apple
network stack. File sharing works out of the box with older clients,
while providing capabilities to print to AppleTalk-only printers.
Netatalk seamlessly interacts with CUPS via the papd
daemon,
enabling older Macs or Apple IIGS clients to print to modern
printers. Via the atalkd
daemon, it can act as an AppleTalk router,
providing both segmentation and zone names in Macintosh networks. In
addition, time server (timelord
daemon) and Apple II netboot (a2boot
daemon)
services are available.
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.
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.
"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 at the 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. 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 (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.
Resources
OS Specific Guides
- Installing Netatalk on Alpine Linux
- Installing Netatalk on Debian Linux
- Installing Netatalk on Fedora Linux
- Installing Netatalk on FreeBSD
- Installing Netatalk on macOS
- Installing Netatalk on NetBSD
- Installing Netatalk on OmniOS
- Installing Netatalk on OpenBSD
- Installing Netatalk on OpenIndiana
- Installing Netatalk on openSUSE
- Installing Netatalk on Solaris
- Installing Netatalk on Ubuntu
Technical Docs
- CatalogSearch
- Kerberos
- Special Files and Folders
- Spotlight
- AppleTalk Kernel Module
- Print Server
- MacIP Gateway
Development