Netatalk 2.2.9 Released

[slipperygrey]

I'm proud to present Netatalk 2.2.9, the latest release in the venerable Netatalk branch that maintains AppleTalk support.

Find the release tarballs on GitHub: https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-2-9

Notably, this version fixes one security vulnerability and one papd printing bug. It also makes atalkd start up more reliably when booting a wifi-only device like a Raspberry Pi. Finally, there is a handful of documentation improvements.

It is a recommended update for all users of netatalk2.

 

[gcp]

Fantastic - thank you!

 

[ScutBoy]

Bravo - thanks!

 

[hauke]

Thanks for all your work!

pkgsrc net/netatalk22 has been updated.

 

[mactjaap]

Super!

 

[slipperygrey]

Thanks for all your work!

pkgsrc net/netatalk22 has been updated.

Thanks for keeping the downstream package alive!

Please let me know if I broke something for NetBSD.

 

[Byte Knight]

Thank you so much!

 

[rollmastr]

Nice!

 

[JAG]

Hey, not sure if this is the place to post, but I've been trying to install Netatalk on a NetBSD 9.3 virtual machine. I updated pkgsrc from CVS and only see v2.2.6 there, not 2.2.9.

Also, how do I start the daemon? I tried putting things like "atalkd_enable=YES" in /etc/rc.conf but can't seem to get the Netatalk daemons to start at boot time.

 

[mactjaap]

My question is almost the same as above.
Using systemd on a RPi doesn’t get the atalk daemon started. By hand… no problem. But not at boot.

 

[NJRoadfan]

This does the trick in Linux with systemd:

sudo systemctl enable atalkd

Should start on every boot after that. I have tested the netatalk-2.x on a RPi running the latest bullseye based OS with no problems. I have not tested 2.2.9, but it should work seeing that the init scripts are the same. NetBSD doesn't use systemd and sticks with classic rc.d scripts, so someone would have to do some debugging.

 

[slipperygrey]

My question is almost the same as above.
Using systemd on a RPi doesn’t get the atalk daemon started. By hand… no problem. But not at boot.

Can you please share the contents of your active atalkd.service file? I want to make sure that you're using the latest version.

And to confirm: The afpd service does start up alright on boot?

 

[slipperygrey]

Hey, not sure if this is the place to post, but I've been trying to install Netatalk on a NetBSD 9.3 virtual machine. I updated pkgsrc from CVS and only see v2.2.6 there, not 2.2.9.

Also, how do I start the daemon? I tried putting things like "atalkd_enable=YES" in /etc/rc.conf but can't seem to get the Netatalk daemons to start at boot time.

@hauke might be able to provide advice here since he's the maintainer of the NetBSD netatalk package.

 

[mactjaap]

OK. Added eth0 to atalkd.conf
And now it works. I thought not touching the conf was the best… but this works fine. Now see if I get my services running!

 

[hauke]

Hey, not sure if this is the place to post, but I've been trying to install Netatalk on a NetBSD 9.3 virtual machine. I updated pkgsrc from CVS and only see v2.2.6 there, not 2.2.9.

Did you per chance 'cvs checkout' the stable branch? I guess that would have an earlier version. One can request pull-ups to the quarterly release branch, but it's mainly done for serious bugs or security issues.

Also, how do I start the daemon? I tried putting things like "atalkd_enable=YES" in /etc/rc.conf but can't seem to get the Netatalk daemons to start at boot time.

That sounds like FreeBSD (who copied NetBSD's rc.d startup system, then "improved" on it, or so they think and Netatalk 3.
For NetBSD, and Netatalk 2, /etc/rc.conf would have something like

atalkd=YES
papd=YES
afpd=YES
cnid_metad=YES
timelord=NO

and you need to copy the Netatalk rc.d files from /usr/pkg/share/examples/rc.d/ to /etc/rc.d/.

 

[akator70]

These may seem like stupid questions, but I haven't been able to find the answer anywhere.

I've got a Linux Mint PC running as my home server with Netatalk 3.1.12 installed from the distro packages. Last summer it worked fine with Mac OS 9. Now Mac OS 9 no longer sees the server and when trying to connect with the IP address there's a login error. After reading threads here and info elsewhere, I determined that it's a good idea to use this version of Netatalk 2.2.9 for my older machines.

Before I do this, these are the questions I haven't been able to find answers to:

1. I have current macOS Macs, older Mac OS X Macs, and classic Macs. If I switch from 3.1.12 to 2.2.9 am I going to lose features for the newer Macs, i.e. file sharing (speed, compatibility, whatever) and Time Machine? My older Mac OS X machines work much better with AFP than they do SMB, so it's clear that I can't be SMB reliant for those.
2. Is it better to have separate machines, one running 3.1.12 for the newer Macs and another running 2.2.9 for the classic Macs?

Thanks.

 

[slipperygrey]

These may seem like stupid questions, but I haven't been able to find the answer anywhere.

Stupid questions are often some of the best ones.

I've got a Linux Mint PC running as my home server with Netatalk 3.1.12 installed from the distro packages. Last summer it worked fine with Mac OS 9. Now Mac OS 9 no longer sees the server and when trying to connect with the IP address there's a login error. After reading threads here and info elsewhere, I determined that it's a good idea to use this version of Netatalk 2.2.9 for my older machines.

This is not right. Netatalk 3.1.x should be perfectly capable of having OS9 clients authenticate with it. If it worked before and stopped working, it could be that your afp.conf changed unexpectedly and no longer loads an OS9 compatible UAM (authentication method.)

The one other suggestion that springs to mind is that your Mint system may have gotten upgraded to OpenSSL 3.0, which broke compatibility with the DHX UAM, which is the default and preferred authentication method for OS9. See https://github.com/Netatalk/netatalk/issues/358 for the discussion.

A workaround in either case is to enable either the clrtxt or randnum UAMs which are less cryptographically secure but more compatible.

Before I do this, these are the questions I haven't been able to find answers to:

1. I have current macOS Macs, older Mac OS X Macs, and classic Macs. If I switch from 3.1.12 to 2.2.9 am I going to lose features for the newer Macs, i.e. file sharing (speed, compatibility, whatever) and Time Machine? My older Mac OS X machines work much better with AFP than they do SMB, so it's clear that I can't be SMB reliant for those.
2. Is it better to have separate machines, one running 3.1.12 for the newer Macs and another running 2.2.9 for the classic Macs?

Thanks.

I wrote this summary in the netatalk FAQ that outlines the differences between 2.2 and 3.1. Spotlight support and improved interoperability with Samba are the two main selling points of 3.1 in my opinion. Time Machine support was introduced with netatalk 2.0.5.

Under the hood, one major difference between 2.2 and 3.1 is how they store Mac file system metadata by default. 3.1 uses macOS style EA metadata, while 2.2 defaults to classic AppleDouble v2. In theory you can convert between the two, but in reality this is a bit of a mess and you easily end up with invalid data that crashes netatalk. So in short I wouldn't recommend trying to use an existing shared 3.x volume with 2.x, or vice versa.

You can certainly run both 2.2.x and 3.1.x on two different machines in the same network and get the best of both worlds. Why don't you try it out while you're getting used to 2.2.x? I personally think 2.2.x is adequate 99% of the time, but your mileage may vary depending on which features you care about.

 

[akator70]

^ Thank you. I kept researching after I posted the questions, but you perfectly explained everything I hadn't been able to piece together yet.

I didn't think about the consequences of the different resource forks, as I've simply been running whatever version of Netatalk is packaged with my Linux distros for over a decade. Many years ago I figured out make sure to make sure the Mac content is stored in sit and (OS X) zip archives to maintain resources. Even with this practice, is it better to sequester the Mac data?

And it sounds like it's better to keep data stored in Netatalk 2.x separate from 3.x? I was thinking about setting up a RPi with Netatalk 2.x as a bridge that connected to the NAS. But since the NAS will be running 3.x, and the drives are already filled with a mish-mash of old and new Mac resource forks, it sound like this RPi plan isn't a good idea...

 

[slipperygrey]

^ Thank you. I kept researching after I posted the questions, but you perfectly explained everything I hadn't been able to piece together yet.

I didn't think about the consequences of the different resource forks, as I've simply been running whatever version of Netatalk is packaged with my Linux distros for over a decade. Many years ago I figured out make sure to make sure the Mac content is stored in sit and (OS X) zip archives to maintain resources. Even with this practice, is it better to sequester the Mac data?

I think you've protected yourself pretty well there. The biggest risk is that your sit files loses their type/creator extended attributes.

And it sounds like it's better to keep data stored in Netatalk 2.x separate from 3.x? I was thinking about setting up a RPi with Netatalk 2.x as a bridge that connected to the NAS. But since the NAS will be running 3.x, and the drives are already filled with a mish-mash of old and new Mac resource forks, it sound like this RPi plan isn't a good idea...

One hidden feature of netatalk 3.x is the automatic conversion of AppleDouble to EA metadata on runtime, which was put into place to make netatalk 2 to 3 migration seamless and automatic. This is always active unless you've explicitly disabled the feature with "convert appledouble = no" in afp.conf. So your volumes very likely have all EA metadata, and no mish-mash per se.

What has been brought to light lately, though, is that somewhere along the way users have ended up with apparently invalid EA headers here and there that are causing mayhem after recent security patches that made header validation stricter. I *suspect* that the invalid data was created by the aforementioned automatic conversion, but I need more data to draw a final conclusion.

So this is why I can't really recommend using volumes created by netatalk 2 with netatalk 3 right now.

See https://github.com/Netatalk/netatalk/issues/236 for the ongoing troubleshooting.

Anyways, if you explain in more detail what you mean by using netatalk 2.x "as a bridge" then I can comment on whether it's a good idea or not?

 

[akator70]

Anyways, if you explain in more detail what you mean by using netatalk 2.x "as a bridge" then I can comment on whether it's a good idea or not?

1. RPi3 with a fstab mounted directory to a directory on the NAS with pertinent .sit and .zip content with is all archived software, then Netatalk 2.x sharing that content with the System 6 - Mac OS 9 machines.
2. A separate shared directory only on the Netatalk RP3 that has uncompressed "native content" for the older machines.
3. A script to zip all of the "native content" assembled in that directory that can then be archived on the NAS for backup. This is of course assuming that RPi OS Lite will properly compress everything including the resource forks.

I personally think 2.2.x is adequate 99% of the time, but your mileage may vary depending on which features you care about.

If I simply replace Netatalk 3.x on the NAS with Netatalk 2.x that would be work with macOS 12-13? The only Apple-specific feature I would like to keep (other than overall file sharing) is Time Machine for the Mac OS X - macOS machines.

What has been brought to light lately, though, is that somewhere along the way users have ended up with apparently invalid EA headers here and there that are causing mayhem after recent security patches that made header validation stricter. I *suspect* that the invalid data was created by the aforementioned automatic conversion, but I need more data to draw a final conclusion.

So this is why I can't really recommend using volumes created by netatalk 2 with netatalk 3 right now.

If I was going to replace Netatalk 3.x with 2.x on the NAS, would it work to simply remove all of the Mac resource files from 3.x before switching to 2.x? That's pretty easy to do with a script.