Netatalk 4.0 - Future-proofing Apple File Sharing

[rdmark]

I pushed a few updates to the verbiage this morning. At the time I had a nice long response typed up, but it got lost due to some browser local storage mishap. Gah!

Good news: In a few months' time, it will soon no longer be true that you need to build from source to get AppleTalk support. Debian, Ubuntu, Fedora, Arch, and Slack have recently packaged netatalk 4.0 which will trickle out to stable distro releases throughout 2025.

Generally speaking, the point with Docker is that it isolates software from the host OS. Traditionally, you install software on a *NIX system by putting hundreds or thousands of files all over the file system, while depending on dozens of libraries of specific versions being available in specific locations (a.k.a. dependency hell). A Docker container on the other hand is an isolated and self-contained file system with access only to the host system's kernel. You bypass dependency hell altogether. This makes it superbly trivial to spin up, update, and tear down software. It's amazing once you get the hang of it.

The netatalk 4.0 Docker container can in fact do AppleTalk as long as the host OS is Linux that's not Red Hat or a Red Hat derivative. This is because the AppleTalk DDP transport layer is situated in the Linux kernel, and Red Hat has purged AppleTalk for security reasons. They don't like old, obscure network protocols.

I don't know if this answers your question though. I see Docker as a somewhat easier way to get started with Netatalk + AppleTalk compared to building from source, for someone who is a beginner with both.

 

[KennyPowers]

That's a great, concise explanation of Docker and the types of problems it solves I think when a lot of people first start learning about containers and Docker, the instinctive thing is to compare containers to virtual machines since they're conceptually similar in a lot of ways. An enlightening distinction then is that VMs virtualize hardware, while containers kind of just virtualize the OS.

 

[Mk.558]

Sounds kinda neat, like iOS in the earlier days with its sandboxy nature.

But shirley you don't get something for nothing. What kind of problems does it introduce? Every type of methodology has certain things it's good at, certain things it's not good at. Of course it's Linux, so the answers usually flip between between "it depends", "...it's complicated..." and "what distro you use".

 

[JDW]

 

[rdmark]

Ha!

The biggest drawback in my mind is the rigidity of the container once you build it. Unlike a normal Linux system, you can't just go in and, say, edit afp.conf and restart netatalk. When you restart the container its state will be reset and changes to afp.conf lost. This is by design, of course. It's how you can guarantee a stable and predictable container. If you need persistence of, say, afp.conf, you need to "bind" it (the file, or the directory that contains it) to a different storage unit (can be another container, or a path on your local file system). If you are familiar with *NIX file systems, you know that it's possible to mount file systems at arbitrary mount points on the directory tree. This is what's happening here.

In a sense, administering a container is more of an inderect activity compared to tinkering directly with a system. You describe to Docker how you want the container to be configured, and then Docker orchestrates it for you.

 

[rdmark]

Good news: netatalk 4 is now available as a Homebrew formula for macOS (and Linux, for you weirdos who use brew on Linux)

If you have brew installed already, just do:

brew update
brew install netatalk
sudo brew services start netatalk

If you're using an Intel Mac, this should work out of the box.

If you're on Apple Silicon, one additional manual step is required:

sudo cp /opt/homebrew/etc/pam.d/netatalk /usr/local/etc/pam.d

If you try it out, please let me know how it went! This my first attempt at creating a brew formula, so there may be other improvement areas.

 

[rdmark]

Netatalk 4.1.0 is available.

Release Netatalk 4.1.0 · Netatalk/netatalk

Netatalk 4.1.0 is available! The Netatalk team is proud to announce the first release in the Netatalk 4.1 release series. This version further improves interoperability on macOS hosts, makes the Ma...

github.com

The standout feature in this version is: When running on a macOS host, afpd now stores Extended Attributes metadata in a macOS native format, rather than as user.org.netatalk.Metadata. This enables seamless retrieval and storage of files with EA metadata onto a shared AFP volume. For instance, if you decompress a StuffIt archive with the Unarchiver on macOS onto a shared AFP volume, any Classic Mac OS file will get extracted with its resource fork data intact.

Also, if you're an OpenWrt fan, you would be pleased to know that it's easier than ever to build netatalk and run it with full AppleTalk support... on supported router hardware. Both netatalk and the OpenWrt kernel has been recently patched.

 

[NJRoadfan]

To clarify, Netatalk 4.1.0 can store/retrieve the resource fork of files natively on macOS hosts without the need of "._" AppleDouble files. Additionally, Netatalk will now natively read and sync any FinderInfo data (File Type/Creator data, labels, etc.) it finds on the host file system.