Netatalk 4.0 - Future-proofing Apple File Sharing

[thecloud]

Leopard was the last version of the Mac OS to support the AppleTalk protocol stack. No version since then has the required support in the kernel, so macOS cannot run atalkd directly. When you fire up atalkd on a macOS host, it will just print an error message and exit. If you want to use a macOS system as a server for System 7 clients (i.e. over AppleTalk instead of TCP/IP), you would need to run a different OS which *does* support AppleTalk in a virtual machine on your Mac.

Your second question is thought-provoking. I'm using Netatalk running in a NetBSD VM on macOS to share a directory on a volume which has over 7GB free. System 7 clients see this share as having less than 2GB free, obviously, but they also see it as using zero K of space, which is clearly not the case. I tried setting legacy volume size = yes in afp.conf and restarting the server, but the results were the same.

 

[NJRoadfan]

The legacy volume size option is only needed in limited situations. Generally with pre-System 7.5 Finder running later (and unsupported) versions of AppleShare Client.

 

[JAG]

The legacy volume size option is only needed in limited situations. Generally with pre-System 7.5 Finder running later (and unsupported) versions of AppleShare Client.

Ah yes, but pre-System 7.5 is essentially all of my use.

 

[thecloud]

Your pre-System 7.5 systems will almost certainly be running the version of AppleShare that was installed with them. You probably didn't install an updated Mac OS 8 or 9 version of the AppleShare client extension onto your pre-7.5 system, which I think is the edge case that this refers to.

It looks like the "0 bytes used" issue is cosmetic only. Doing a "Get Info" on individual files or folders shows their correct size. But the numbers in the share's Finder windows (zero K in disk, 2,047.9 MB available) never change, even after copying several MB of data to the server. This makes me think I have probably missed something in my configuration. I'm using appledouble = v2 and ea = ad. The dbd utility warns that the volume does not support Extended Attributes and says "Unknown Extended Attributes option: 0" but everything else seems ok.

 

[NJRoadfan]

The zero K on disk is normal. The AppleShare clients in question support AFP2.2, which has extended disk size and free space commands to report over 2GB/4GB of disk space free or used. Older versions of Finder only allocated a 32-bit value for these values (later unsigned), and would overflow on larger shares causing problems.

@thecloud, I was under the impression that NetBSD 10 supported extended attributes out of the box?

 

[thecloud]

@thecloud, I was under the impression that NetBSD 10 supported extended attributes out of the box?

That's what I thought too, but apparently I must have deselected it when I installed NetBSD because:

arm64# dumpfs / | head
file system: /dev/rdk1
format  FFSv2
endian  little-endian
...

which means I didn't get extended attributes. If I had, the format would have been FFSv2ea. It looks like I can turn them back on, but also, "FFSv2ea file systems are not compatible with any other operating system" so maybe that's why I decided against it.

 

[slipperygrey]

A quick tally on the Netatalk v4 adoption in downstream distribution channels:
The OSes and 3rd party repos that now distribute a version of Netatalk 4 are...

1. Arch Linux
2. Debian GNU/Linux
3. Devuan GNU+Linux
4. Fedora
5. Homebrew
6. Kali Linux
7. Mageia Linux
8. NetBSD
9. OpenBSD
10. OpenWrt
11. PureOS
12. Raspberry Pi OS
13. Slackware
14. Ubuntu

In the works, that I know of, are...

1. NixOS
2. MacPorts

Anyways, I'm very pleased with the adoption so far, only 4 months after release. The notable laggards are Alpine Linux and Gentoo, which still distribute the older 3.1, as well as FreeBSD which upgraded their port to 3.2 a few months ago.

 

[slipperygrey]

This is more of a niche project update than usual, but I'm proud to share that as of today I've put in place structures that allow anyone to translate the Netatalk manual to other languages, and have them published on the netatalk.io website in the future. (Or be packaged by distros that package localized docs, and then read locally.)

To summarize the technical details: Before, the manual was kept in XML format, and then transformed with DocBook XSL to roff man pages or html pages. DocBook is a fine and capable technology, but it's very old school, rigid, and slow. So I worked a few late night to convert the whole manual, all readmes, and the entire website to modern Markdown (using pandoc to automate the process) and then polished it until it shone.

A preview version of the html manual is online at https://netatalk.io/manual/en/

Additionally, since the early 2010s there's been a Japanese localization of the Netatalk manual that's been effectively operated as a separate project by two diligent community members. They abandoned the project a few years ago, after which I pulled it into Netatalk proper. However, their approach was to take a copy of the 10k+ lines of XML code and hard code the translations, so to speak. Needless to say, keeping the translation up to date has been extremely cumbersome.

So as part of the Markdown transition, I introduced po4a, a gettext based tool, to break translations out of the source code. Now it's as easy as editing three files, running po4a, and then go crazy with translation in the resulting po files.

If someone feels up for translating just under 1200 strings of technical documentation, here's a guide for getting started.

 

[Joopmac]

Extremely interested in this. Is there a compiled version for n00bs like me? A simple .pkg installer that installs the Appletalk daemon with the AFP server would be sooo sweet!!

 

[slipperygrey]

Extremely interested in this. Is there a compiled version for n00bs like me? A simple .pkg installer that installs the Appletalk daemon with the AFP server would be sooo sweet!!

You're talking about an installer for macOS, right?

You can use Homebrew to get a compiled version of netatalk ready to run.

Please note that we don't have an AppleTalk stack on macOS. Apple did away with it in 2009. Linux and NetBSD are your options for AppleTalk goodness right now.

 

[Joopmac]

Right=) ah, i misread and thought the AppleTalk protocol was back for arm64 architecture….

 

[Mk.558]

If you start a new GitHub Discussions thread, we can try a little troubleshooting again, if you like.

I bet the "DDP/IP situation" referred to the now-removed IPDDP Linux kernel module. It conflicted with macipgw operation.

macipgw does not work properly with FTP · Netatalk netatalk · Discussion #1884

Since the integration of macipgw into Netatalk, I took the time to try it out. FTP is not reliable under NAT. However we should be able to figure out why. Active FTP was common in the early 1990s a...

github.com

Looks like I'm the only one.

 

[mactjaap]

I have some problems with my papd setup on Netatalk 4.1.1 on a Raspberry Pi
I managed to get it working on the 2.4.* branch. But now with the upgrade I have some errors I don't understand.

If I do a /usr/local/sbin/papd -d I can see what is happening:

root@maciprpi:~# /usr/local/sbin/papd -d
papd: Set syslog logging to level: debug
papd: restart (4.1.1)
papd: CUPS support enabled (2.4)
papd: Authentication disabled: HP_LaserJet_Pro_M118dw_6071AC
papd: register HP_LaserJet_Pro_M118dw_6071AC:LaserWriter@*
papd: Unable to get destination "lp": The printer or class does not exist.
papd: No such CUPS printer: 'lp'
papd: printcap problem: lp
papd: can't register root:LaserWriter@maciprpi
papd: unregister HP LaserJet Pro M118dw 6071A#01:LaserWriter@*
papd: Deleting CUPS temp PPD file for HP LaserJet Pro M118dw 6071A#01 (/tmp/0619a67ba7bd9)
papd: Deleting CUPS temp PPD file for HP LaserJet Pro M118dw 6071AC (/tmp/0619a67bf8f16)

My config is like this:

root@maciprpi:~# cat /etc/netatalk/papd.conf
# PAP print server daemon configuration (Netatalk 4.x)
#
# See the `papd.conf' manual page for examples.

# Uncomment the following line to share all CUPS enabled printers.
cupsautoadd:op=root:
root@maciprpi:~# cat /etc/netatalk/papd.conf
# PAP print server daemon configuration (Netatalk 4.x)
#
# See the `papd.conf' manual page for examples.

# Uncomment the following line to share all CUPS enabled printers.
cupsautoadd:op=root:

It is trying to find a CUPS printer lp and it cannot find it. It also tries to add a non existing printer:

HP LaserJet Pro M118dw 6071A#01

If I start it as a service it will restart over and over.

Not sure what is happening here....
I anyone has an idea.. help is welcome!

 

[mactjaap]

OK.... lesson learned... typo's in a conf are no good....
Now it is fixed! I had some garbage in my conf.

 

[pl212]

Here's a quick question: is case respected in afp.conf for volume names? Say I have this volume:

[Applications]
path = /home/pi/Applications
legacy volume size = yes

In Netatalk 4.20dev, it shows in the both the classic Chooser and modern MacOS as applications, not Applications. Noticed this as part of my upgrade from 2.4.x to 4.x...

 

[thecloud]

That's strange. The documentation for afp.conf says that section names are case sensitive. For the above entry, the section name [Applications] means you should be seeing Applications as the volume name (i.e. the section name minus the enclosing brackets). The path value doesn't have to contain that name and can point anywhere. Does the lower-case applications string appear anywhere else in afp.conf? Do you have any case-related options set in the Global section?

 

[slipperygrey]

Here's a quick question: is case respected in afp.conf for volume names? Say I have this volume:

[Applications]
path = /home/pi/Applications
legacy volume size = yes

In Netatalk 4.20dev, it shows in the both the classic Chooser and modern MacOS as applications, not Applications. Noticed this as part of my upgrade from 2.4.x to 4.x...

Good catch. This is a recent breakage in bleeding edge 4.2.0dev. In recent weeks I've been hard at work protecting against race conditions, memory leaks and buffer overflows, so it's no surprise that there are a few bugs!

Another breakage right now is that the home dir share doesn't show up.

If you want a stable experience, I recommend branch-netatalk-4-1!

But then again, I really appreciate you finding bugs for me in bleeding edge.

 

[slipperygrey]

@pl212 I figured out what caused the breakage:

When stripping out the vendored iniparser library that netatalk has been using for over a decade, and linking with the system's shared iniparser library instead.

Among the minute differences between the netatalk iniparser fork, and upstream iniparser, is that the latter converts all section names to lowercase internally. And netatalk uses the section name for the shared volume name, so...

And by that same logic, the Homes section gets converted to "homes" internally which the netatalk code does not recognize.

The latter is easily fixed. But the former is a deeper design decision really. I don't think the author of iniparser intended for the section names to be used for anything else than an internal identifier. So it's arguably a hack that netatalk uses them for something else.

I have two choices: Revert the de-forking of iniparser, or create a workaround in netatalk code.

I really don't want to do the former. Maintaining a forked library is overhead I want to minimize. The iniparser library has recently gotten new management and is pushing out new releases rapidly.

So my proposal is: Introduce a "name" option to volume sections where you can define a case sensitive volume name. This changes the default behavior a bit, but I promise to make that clear in the upcoming release notes.

Thoughts?

 

[pl212]

That all sounds good! I could imagine some situations where there is an advantage to having a slug-like short label and a lengthier display name argument. (Not least in non-Englsih contexts.)

I wonder if the new name argument could be optional, to stop existing 4.x configs from breaking?

 

[slipperygrey]

It was easily achieved! This PR takes care of both issues: https://github.com/Netatalk/netatalk/pull/1968

In fact, introducing the new "name" option for volumes was literally adding a single line of code. One additional line change to keep the default fallback behavior. I think it demonstrates how handy the iniparser library is!