User authentication failing on macOS ARM

[EricFromCanada]

Following up on Homebrew/homebrew-core#202713 (comment):

I've installed the forthcoming netatalk Homebrew formula on a few systems. On Intel, serving a user's home directory works fine. On ARM, it consistently rejects connection attempts.

I've tested using Intel macOS 13 and 14 VMs via VMware Fusion, an ARM macOS 13 VM via UTM, and an ARM macOS 14 Mac. On each I installed the formula, added log file = /tmp/netatalk.log and log level = default:info to afp.conf, and ran sudo netatalkd start with tail -f /tmp/netatalk.log in another tab.

On Intel:

Jan 08 13:14:01.955342 afpd[6779] {dsi_tcp.c:240} (info:DSI): AFP/TCP session from 192.168.250.1:55404
Jan 08 13:14:01.958962 afpd[6779] {uams_dhx2_pam.c:325} (info:ad): DHX2 login: vmadmin
Jan 08 13:14:01.981194 afpd[6779] {uams_dhx2_pam.c:210} (info:ad): PAM DHX2: PAM Success
Jan 08 13:14:02.190543 afpd[6779] {uams_dhx2_pam.c:705} (info:ad): DHX2: PAM Auth OK!
Jan 08 13:14:02.190959 afpd[6779] {auth.c:246} (note:AFPDaemon): Login by vmadmin (AFP3.4)
Jan 08 13:14:21.076551 afpd[6779] {auth.c:827} (note:AFPDaemon): AFP logout by vmadmin

On ARM:

Jan 08 09:55:48.814679 afpd[10468] {dsi_tcp.c:240} (info:DSI): AFP/TCP session from 192.168.66.1:57399
Jan 08 09:55:48.818786 afpd[10468] {uams_dhx2_pam.c:325} (info:ad): DHX2 login: vmadmin
Jan 08 09:55:48.865310 afpd[10468] {uams_dhx2_pam.c:662} (info:ad): DHX2: PAM_Error: authentication error
Jan 08 09:55:48.866076 afpd[10468] {afp_dsi.c:113} (note:AFPDaemon): AFP statistics: 0.51 KB read, 0.38 KB written via DSI
Jan 08 09:55:48.866662 afpd[10468] {dircache.c:612} (info:AFPDaemon): dircache statistics: entries: 0, lookups: 0, hits: 0, misses: 0, added: 0, removed: 0, expunged: 0, evicted: 0
Jan 08 09:55:48.867909 afpd[10456] {main.c:178} (info:AFPDaemon): child[10468]: done

I'll note that on ARM it's able to receive connections to a separate share with uams_guest.so enabled.

Has anyone else encountered this?

[rdmark]

One idea that springs to mind is to make sure the PAM config path translates correctly on the affected systems. In the homebrew formula we defined the path with -Dwith-pam-config-path=#{etc}/pam.d but maybe this is not correct for your particular combination of architecture and macOS versions?

FWIW: My main testbed is an M1 Mac running macOS 15, and have not experienced this issue. So it's not a fundamental breakage on ARM Macs either...

[EricFromCanada]

I've found that copying /opt/homebrew/etc/pam.d/netatalk to /etc/pam.d or /usr/local/etc/pam.d allows authentication to immediately work, no server restart needed.

Looking at the manpage for pam.conf, it seems macOS only searches /etc/pam.d and /usr/local/etc/pam.d for policy files, and there doesn't seem to be a way to add any to the search path. This would explain why authentication happens to work when installed on Intel (with a Homebrew prefix of /usr/local) but not on ARM (with /opt/homebrew). Since writing to either path would require sudo, the formula would have to display a caveat that the file needs to be copied manually.

[rdmark]

That would do it! I can put up a PR tomorrow with the code change for displaying said message.

And on my testbed M1 Mac, I of course already had the PAM config path in the right place because I have been installing netatalk directly a million times. So I didn't see the issue.

One potential solution would be to disable PAM altogether with -Dwith-pam=false and fall back to traditional *nix style auth. However, last I tried this doesn't work on macOS right now (while it works on Linux, BSD and Solaris). It might be an Apple API or policy thing we need to figure out.

[EricFromCanada]

I have a message added in this PR draft here: https://github.com/Homebrew/homebrew-core/pull/203754/files

[rdmark]

Beautiful!

FWIW, the next release will be 4.1.0. As a minor feature release, it will improve on filesystem EA integration on macOS, among other exciting additions.