• 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

slipperygrey

Well-known member
As always, thanks for your work!

I nstalled the updated 'net/netatalk22' pkgsrc package on my home server a few days ago, and (after minor debate on the package name - back when the package was generated, nobody reasonably expected any further release on the branch...) just committed it to the repository.
Thanks for keeping the NetBSD package up to date! I've also been pondering what an appropriate name for a stand alone v2 project should be. Chris K. called it "netatalk-classic". Your idea of "netatalk-ddp" isn't bad either, for those who know what DDP stands for.

BTW a minor thing, but the "master sites" URL on https://pkgsrc.se/net/netatalk22 is incorrect; it should be: https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-3-0
 

hauke

Active member
Thanks for keeping the NetBSD package up to date! I've also been pondering what an appropriate name for a stand alone v2 project should be. Chris K. called it "netatalk-classic". Your idea of "netatalk-ddp" isn't bad either, for those who know what DDP stands for.
The correct name would be "netatalk-appletalk", but that is a bit hilarious.
BTW a minor thing, but the "master sites" URL on https://pkgsrc.se/net/netatalk22 is incorrect; it should be: https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-3-0
For which value of "incorrect"?

The Makefile's MASTER_SITES variable expands to "https://github.com/Netatalk/Netatalk/releases/download/netatalk-2-3-0/", which works when you append netatalk-2.3.0.tar.xz - I just tried. Previous versions were accessible under the same path, I just updated the version information.

But github's download links are a mess, I've seen all kinds of patterns. There is no systematics.
 

slipperygrey

Well-known member
Netatalk v2.3.1 is available now. This is a bugfix and compatibility release.

Notably, this improves the buggy RMTP broadcast behavior that we attempted to fix with the atalkd "quirks" (-q) mode in 2.3.0.
Now atalkd should automatically detect if it needs to run in quirks mode, which should improve compatibility with AppleTalk networks that has multiple routers.

Additionally, the CUPS code in papd has seen major refactoring and modernization of CUPS API calls.
This should improve compatibility with printers, while making it future proof in anticipation of CUPS 3.0.

Huge thanks to @NJRoadfan for his hard work on both of the above!

See the release notes for more details and download links.
https://netatalk.io/2.3/ReleaseNotes2.3.1

You may also notice the new netatalk.io domain.
Thanks SourceForge for two decades of hosting. :)
 

slipperygrey

Well-known member
More Netatalk news! Building upon a POC by community member @eharmon I was able to put together a more or less fully functioning Docker setup for netatalk2. And now I'm looking for volunteers to try it out, and hopefully hear back if it works for you or not.

To get started, check out this git branch: https://github.com/Netatalk/netatalk/tree/rdmark-docker-v2

Instructions are in the root README.md

I have to say, for me and a handful of other people, it works remarkably well...
 

ironborn65

Well-known member
this is good, thanks.
I don't see the image being pushed to a registry, e.g. docker hub.
I'd need this to install it in my Synology.
Yes I could build it locally and upload it ... ;)

there are several other Netatalk images, some very recents, one from the official Netatalk maintainer would be a good thing
 

slipperygrey

Well-known member
Once the docker setup is finalized and stable I’ll look into pushing to registries. Thanks for the suggestion!
 

ironborn65

Well-known member
thanks @slipperygrey

foreword: I'm moving out of my comfort zone

I disabled the AFP in my Synology NAS 218+
I downloaded both images, netatalk21 and netatalk31
I configured the mandatory variables AFP_USER, AFP_PASS, ATALKD_INTERFACE the latter matching the IP of the NAS.

My test machine is a UTM VM with OS9.2.1 running in a MacOS. It can access the internet. It's the VM I use to share folders with the retro non virtualised Macs.

I started the container.
I can not see the netatalk server also if adding the server manually in OS9.2.1. The same with netatalk21.
Of course 31 and 21 don't run concurrently.

The logs are attached hereby.

Even if the Avahi is not supported in the Synology NAS, at least it should work if configured manually.
Can u, or someone else, advice?
 

Attachments

  • netatalk-netatalk31.html.zip
    1.9 KB · Views: 1
  • netatalk-netatalk21.html.zip
    1.1 KB · Views: 2

slipperygrey

Well-known member
@ironborn65 Yes, you should be able to connect to the AFP server by IP even if Avahi or AppleTalk aren't working.

For the netatalk container running on your NAS, are you using host networking, or are you exposing port 548? Maybe you have to manually open port 548 on the NAS when the built-in AFP server is disabled?

BTW, you can use your contemporary macOS system as a test bed as well. In the Finder, do CMD+K to bring up "Connect to Server" then type "afp://" and the address to the NAS.

This page might be helpful: https://netatalk.io/docs/Connect-to-AFP-Server-from-Mac-clients
 

ironborn65

Well-known member
from the MacBook M1 the afp:// works, I can authenticate, good, NAS wise it's all set

instead from Basilisk II + System 7.5.3 + O.T 1.1.2 + Apple Talk 60.1.2 active + Apple Client Present
I have a "This file server does not use a recognizable log on sequence."
From this VM I can access the NAS by IP or domain name, so the network configuration should be ok
 

slipperygrey

Well-known member
@ironborn65 What version of the Apple Share Client are you running on the 7.5.3 system? That error means that the connection to the AFP server is successful, but that there is no compatible authentication method.

In fact, I was under the impression that the RandNum UAM would work out of the box with practically any version, but if this is not the case we have to revisit the decision not to include the ClrTxt UAM.
 

ironborn65

Well-known member
when working with the modern MacOS:

I must map my shared NAS folder to /mnt/afpshare, otherwise it does not work.
In fact I can find the files in the container, in root@netatalk-netatalk31:/mnt/afpshare# and the MacOS correctly sees it when "Connect to Server...".

If I try to map a different folder to /mnt/logs (for example), the folder is correctly reflected in the container, but in the MacOS the volumes I see are only "File Sharing" and "Time Machine", my "logs" is not shown. Is this an expected behaviour?

After adding the file from the MacOS, the container log shows up some errors, the report log is attached.
I hope this helps.
 

ironborn65

Well-known member
@ironborn65 What version of the Apple Share Client are you running on the 7.5.3 system? That error means that the connection to the AFP server is successful, but that there is no compatible authentication method.

In fact, I was under the impression that the RandNum UAM would work out of the box with practically any version, but if this is not the case we have to revisit the decision not to include the ClrTxt UAM.
TattleTech reports:
◊ AppleShare Client is Present = Yes
+ AppleShare Client is Running = Yes
+ AppleShare Client Version = [Unknown]

Any other way I can check the version?
 

ironborn65

Well-known member
when working with the modern MacOS:

I must map my shared NAS folder to /mnt/afpshare, otherwise it does not work.
In fact I can find the files in the container, in root@netatalk-netatalk31:/mnt/afpshare# and the MacOS correctly sees it when "Connect to Server...".

If I try to map a different folder to /mnt/logs (for example), the folder is correctly reflected in the container, but in the MacOS the volumes I see are only "File Sharing" and "Time Machine", my "logs" is not shown. Is this an expected behaviour?

After adding the file from the MacOS, the container log shows up some errors, the report log is attached.
I hope this helps.
 

Attachments

  • netatalk-netatalk31.csv.zip
    2.7 KB · Views: 0

slipperygrey

Well-known member
TattleTech reports:
◊ AppleShare Client is Present = Yes
+ AppleShare Client is Running = Yes
+ AppleShare Client Version = [Unknown]

Any other way I can check the version?
Find the AppleShare or AppleShare Client extension and do "Get Info" on it.
Screenshot 2024-02-12 at 22.48.16.png
 

slipperygrey

Well-known member
when working with the modern MacOS:

I must map my shared NAS folder to /mnt/afpshare, otherwise it does not work.
In fact I can find the files in the container, in root@netatalk-netatalk31:/mnt/afpshare# and the MacOS correctly sees it when "Connect to Server...".

If I try to map a different folder to /mnt/logs (for example), the folder is correctly reflected in the container, but in the MacOS the volumes I see are only "File Sharing" and "Time Machine", my "logs" is not shown. Is this an expected behaviour?

After adding the file from the MacOS, the container log shows up some errors, the report log is attached.
I hope this helps.
Yes this is the expected behavior. In order to share another directory in the container, you have to modify the /usr/etc/netatalk/AppleVolumes.default file (netatalk2) or /usr/etc/afp.conf file (netatalk3).

Earlier today I pushed an update to the netatalk images that introduces a "MANUAL_CONFIG" option that you can enable to stop the entry script from rewriting the config files every startup. That way you can do whatever you want to the configuration and have it be persistent (I think.)
 

slipperygrey

Well-known member
@ironborn65 Actually, were you in fact running the netatalk3 image when you got the "This file server does not use a recognizable log on sequence." error?

The netatalk3 image is using the DHX UAM for authentication which requires at least AppleShare Client 3.8.4.

The netatalk2 image is using the more backwards-compatible RandNum UAM.
 
Top