• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Netatalk 2.3.0 available

robin-fo

Well-known member
@mathieutozer More likely, this is due to the lack of AppleTalk support. atalkd is only used for AppleTalk and AFP over DSI/TCP should work without it. I don‘t know how this docker image works, but disabling AppleTalk support in Netatalk is probably the way to go.

Currently, my preferred way to run Netatalk on a Mac is inside a Linux VM. Install UTM and a prepare lightweight Ubuntu Server setup. Then compile and install Netatalk. My preferred way to do this is using the PiSCSI installer.
 
Thanks for the tips!

Wouldn't I need AppleTalk to share files with my classic Macs though? I also was just running locally to try things out, ultimately I would want to have it hosted someplace like heroku though.

Currently trying to figure out how to get the heroku compose command to upload the image...
 

slipperygrey

Well-known member
You do need AppleTalk to connect with System 7.0 clients and earlier. Later Mac OS versions are able to run AppleShare Client software that supports TCP.

If of course is “nicer” to have AppleTalk for any classic Mac OS client since you get the handy automatic service discovery and some other neat utility.

The https://netatalk.io website has a lot of resources on this topic that you can read up on.

Anyways, this report did bring to light one shortcoming of the netatalk2 docker image: It does not fail gracefully when you try to run it on a host that lacks an AppleTalk network stack. The original idea was that if you don’t need AppleTalk, you might as well run netatalk3 instead. But on the other hand, I’m thinking now that it would be more user friendly to throw a more descriptive error message, and then fall back to run the container without atalkd.

Any other thoughts or ideas how to do in this situation?
 

slipperygrey

Well-known member
@robin-fo The new macOS init script is in the bleeding edge 2.3 branch now. You enable it by passing the newly added "--enable-macos" parameter to the configure script.

It comes with two facilities: a "netatalkd" wrapper script for starting cnid_metad and afpd with the right env variable, and a com.netatalk.daemon.plist launchd job configuration.

The former is used to control the netatalk daemons manually, and the latter for telling launchd to start netatalk when macOS boots up.

After building and installing, you can use it like this:

Code:
sudo netatalkd start

And to stop the daemons:

Code:
sudo netatalkd stop

Or if you prefer to leave it up to the OS, register netatalk with launchd:

Code:
sudo launchctl enable system/com.netatalk.daemon
launchctl start netatalk
 

robin-fo

Well-known member
Cool! Many thanks for your efforts! I was able to start Netatalk 2 on the Mac with the suggested workaround.
 

slipperygrey

Well-known member
Cool! Many thanks for your efforts! I was able to start Netatalk 2 on the Mac with the suggested workaround.
Yay! You're welcome.

Mind you, this is only a workaround. Apple may decide to shut down this override in the future.

Reading up on the various blog posts on the topic, what I understand is that *NIX-style forking is inherently incompatible with multi-threading. If you fork a multi-threaded process, only the thread that created the fork will survive, and the other threads will die. Needless to say, this can lead to a Bad Time if those other threads were doing memory allocation stuff. You may be fine if you're lucky, but it can lead to insidious fail states. (I'm just paraphrasing; a true expert can correct me if I'm misrepresenting this. :) )

Apple's failsafe here is built into ObjC, and while netatalk is plain C and not multi-threaded, we sometimes call macOS foundational libraries. LDAP, Kerberos, etc. And when an ObjC class is initialized it will check for forking processes and bail out if it sees a suspected "misbehaving" process.

In the future, we may have to re-architecture afpd to not be a forking process, OR reduce the dependency on macOS foundational libraries.
 

slipperygrey

Well-known member
A stable Netatalk 2.3.2 release has been tagged and released now:


All of the recent feedback and bug reports in this thread should have been resolved now.

One last minute breaking change: I renamed the macOS launchd daemon to match the new https://netatalk.io website domain. The new name is:

Code:
io.netatalk.daemon

So if you installed the daemon with its earlier name via the earlier development code, you will have to disable and purge the previous one if you want to avoid it going stale in the future.

A huge thanks again everyone who used and provided feedback and code to the Netatalk project. You all are the reason I keep this project alive!
 

slipperygrey

Well-known member
Some (experimental) progress with running Netatalk 2 on macOS using my userspace AppleTalk stack. This demo used LToUDP as data link, but EtherTalk or a TashTalk connected using a USB to Serial adapter should be possible at no cost. (ok well, TashTalk support in my stack is still somehow buggy..)
This is very, very neat! It blows my mind to see these enthusiast made pieces of software come together like this on top of the latest macOS.

BTW you're exposing some personal information in this video. Just in case you didn't notice and would like to redact it. ^^;
 

CTB

Well-known member
I wasn't sure where to post this but it is Netatalk 2.3 related. I want to turn off guest access. I figured it would be easy and I can read man pages. I was wrong, I have been going down blind alleys and scratching my head for days.

Can someone explain to me how I turn off guest access to my netatalk 2.3 server running on a Raspberry Pi?
 

slipperygrey

Well-known member
I wasn't sure where to post this but it is Netatalk 2.3 related. I want to turn off guest access. I figured it would be easy and I can read man pages. I was wrong, I have been going down blind alleys and scratching my head for days.

Can someone explain to me how I turn off guest access to my netatalk 2.3 server running on a Raspberry Pi?
TL;DR: You need to edit your afpd.conf file and then restart afpd.

If you don't know where your afpd.conf file is, you can run "afpd -v" to see where it is located.

Then edit afpd.conf and remove "uams_guest.so" from the list of UAMs.

Finally restart afpd. If you are running Raspberry Pi OS this is done with "sudo systemctl restart afpd".

This should do the trick. You can run "asip-status localhost" to inquire the Netatalk server about its capabilities, including the active UAMs (authentication modules).

BTW, don't hesitate to start a new GitHub Discussion thread for any future technical support request: https://github.com/Netatalk/netatalk/discussions
 

CTB

Well-known member
Great, thank you. That did work however I tried asap-status localhost and got a command not found error.
 

cathrynmataga

New member
Just want to report in, that I did get this working with guest access on raspberry pi with the 64-bit OS installed, and now I'm happily moving files to and from my eMac running MacOS9. Thanks to everyone who has kept this thing running
 

slipperygrey

Well-known member
If someone wants a more light-weight OS for their netatalk 2.x server, I've confirmed that Alpine Linux in its standard configuration happily supplies the appletalk kernel module when needed.

I wrote a guide here: https://github.com/Netatalk/netatalk/wiki/Installing-Netatalk-2-on-Alpine-Linux

For the next stable 2.x release, I plan to migrate the official Docker image to an Alpine Linux base image. Lighter and with a smaller attack surface!
 

akator70

Well-known member
I've setup a "new" RPi3 server running RPi OS Lite with Netatalk 2.3.x. Just a heads up for anyone else trying to use the Webmin module...
  1. An additional dependency needs to be installed: sudo apt install libcgi-session-perl -y
  2. The Netatalk Webmin module will work, but the module configuration paths need to be changed to /usr/local/sbin/, specifically:
    1. /usr/local/sbin/afpd
    2. /usr/local/sbin/atalkd
    3. /usr/local/sbin/papd
Once I figured those out, everything is running perfectly.

Thanks to all of the amazing people who made this happen!
 

slipperygrey

Well-known member
Good stuff, thanks for sharing your setup! In particular, it’s encouraging to hear that the 2.x webmin module is actually being used in the wild. :)

I think your first point is actually a bug in the webmin packaging itself. The webmin deb should handle the full dependency tree when being installed. Would you be up for reporting it to that project?

Regarding your second point, these exact paths are dependent on the sysconf prefix used when building netatalk. Just saying for the record if someone uses this thread as reference in the future. You can inquire netatalk of the conf file paths it used by running “afpd -V”

I have an improvement idea of making a monorepo that has both netatalk and webmin code, because the build system will know the exact sysconf prefix and automatically modify the webmin module config on the fly as it installs everything.
 
Top