Netatalk 4.0 - Future-proofing Apple File Sharing

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.

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.