Netatalk 2.3.0 available

ironborn65 · Feb 12, 2024

slipperygrey said:
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.)

thanks.
instead of the MANUAL_CONFIG you can map the config file in another mapped Volume, as such it will be persistent.
No need to add another parameter to the run script
volumes:
- "./AppleVolumes.default: /usr/etc/netatalk/AppleVolumes.default"
It's a best practise to map config files to Volumes.

I don't find AppleShare Client 3.8.4. but even V3.8.3 requires system 8. V3.8 does not work,
No way for a 7.5.3 to use netatalk 3.1 then?

Why for not supporting RandNum UAM in v3.1? Is the goal to reduce the footprint?

slipperygrey · Feb 13, 2024

ironborn65 said:
thanks.
instead of the MANUAL_CONFIG you can map the config file in another mapped Volume, as such it will be persistent.
No need to add another parameter to the run script
volumes:
- "./AppleVolumes.default: /usr/etc/netatalk/AppleVolumes.default"
It's a best practise to map config files to Volumes.

Thanks for sharing. That's a neat trick.

ironborn65 said:
I don't find AppleShare Client 3.8.4. but even V3.8.3 requires system 8. V3.8 does not work,
No way for a 7.5.3 to use netatalk 3.1 then?

Why for not supporting RandNum UAM in v3.1? Is the goal to reduce the footprint?

There is a way (using Random Number or Clear Text UAMs) but they're insecure which is why I decided to disable them by default in the netatalk3 image. You can of course use a local override for afp.conf to enable those UAMs if you want to. You can use v3 with as old as System 7.1 clients with an easy hack.

To summarize the purposes I had in mind for the two images:

netatalk3 --

Relatively strong crypto (DHX) for Mac OS 9, 8, 7.6; strong crypto (DHX2) for Mac OS X, macOS
Better support for Mac OS X / macOS: AFP 3.4, Spotlight, OSX style EA metadata, OSX friendly extension mapping
Better Samba interoperability

netatalk2 --

Weak crypto (RandNum) for Mac OS 9, 8, 7.6, 7.5, 7.1, 7.0, 6.0, GS/OS; and strong crypto (DHX2) for Mac OS X, macOS
Better support for Classic Mac OS and Apple II: AppleTalk service discovery, creator/type extension mapping, AppleDouble metadata
AFP 1.1 and AppleTalk for easy networking with Apple IIe and IIGS
AppleTalk print server, time server, Apple II netboot server

Frankly, there is a pretty big overlap in the Venn diagram between the two that isn't covered above (AFP 2/3, Bonjour, Time Machine etc.). My shorthand recommendation is: if your network only has Mac OS X 10.2 clients or later, run v3. If you have anything earlier, run v2.

Hope this helps!

ironborn65 · Feb 13, 2024

fine, thanks.

So I tried with v2.1
but the server does not respond in MacOS and System 7.5.3
ps -ax in the container show only:
root@netatalk-netatalk21:/mnt/afpshare# ps -ax
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash /docker-entrypoint.sh
38 pts/0 S+ 0:00 afppasswd -a ironborn65
50 pts/1 Ss 0:00 /bin/bash
56 pts/1 R+ 0:00 ps -ax

apparently the docker-entrypoint.sh is stuck as afppasswd.
The container log reports:

slipperygrey · Feb 13, 2024

That one I haven’t seen before. Any chance you can shut down the container, delete it and clear out the image chance, then pull it again? Since you’ve been trying out various revisions of the image maybe something got messed up on the container file system.

ironborn65 · Feb 13, 2024

Hi, nope; I've started and re-created the container several times from a clean environment.
In any case the execution of the docker entrypoint does not depend on the host, it's self contained.
netatalk process never started in v2.1

The v3.1 container has not "ps" installed, I don't find the dockerfile so I can not check the FROM directive or the package installations commands

slipperygrey · Feb 13, 2024

Now I get it. The v2 image never worked for you, right?

At the spot where afppasswd stops for you, I’m using a bash trick called “here document” which starts a new script context, and then returns to the original context when finished. My theory is that the version of docker on your NAS trigger some corner case behavior with here documents and can’t break out of it.

I’m traveling right now but once I’m back home in a few days I’ll try variants on that syntax and see if we can figure it out…

The Dockerfile code can be found in these working branches:

GitHub - Netatalk/netatalk at rdmark-docker-registry-v2

Netatalk is a freely-available Open Source AFP fileserver. A UNIX, Linux or BSD system running Netatalk is capable of serving many Macintosh clients simultaneously as an AppleShare file server (AFP...

github.com

GitHub - Netatalk/netatalk at rdmark-docker-v3

Netatalk is a freely-available Open Source AFP fileserver. A UNIX, Linux or BSD system running Netatalk is capable of serving many Macintosh clients simultaneously as an AppleShare file server (AFP...

github.com

The v3 is using a different base image which must be why it’s lacking the ps command. (It’s a long story. I need to use an older version of Debian to get OpenSSL 1.1 for a functioning DHX UAM.)

ironborn65 · Feb 13, 2024

FYI

Synology 218+ , docker version

Client:
Version: 20.10.3
API version: 1.41
Go version: go1.17.1
Git commit: 55f0773
Built: Thu Jul 21 10:23:46 2022
OS/Arch: linux/amd64
Context: default
Experimental: true

twelvetone12 · Feb 13, 2024

Hi @slipperygrey! Many thanks for your great work on netatalk and the docker image! I tried it with with the kernel tashtalk diiver and LT2USB and it work as a charm - almost. It seems that netatalk gets stuck in ATP transactions while doing AFP - it is a problem I have patched on my manually installed version too. Basically in the ATP handler in at_addr_eq() the second address is not checked for ATADDR_ANYNET, and everything just deadlocks. Did you ever encounter this issue? Should I open an issue in teh github tracker?

EDIT: It really seems to affect only AFP, printing works!

slipperygrey · Feb 13, 2024

twelvetone12 said:
Hi @slipperygrey! Many thanks for your great work on netatalk and the docker image! I tried it with with the kernel tashtalk diiver and LT2USB and it work as a charm - almost. It seems that netatalk gets stuck in ATP transactions while doing AFP - it is a problem I have patched on my manually installed version too. Basically in the ATP handler in at_addr_eq() the second address is not checked for ATADDR_ANYNET, and everything just deadlocks. Did you ever encounter this issue? Should I open an issue in teh github tracker?

EDIT: It really seems to affect only AFP, printing works!

Ooh, that is a bug that I have not encountered in my LocalTalk Bridge environments! I wonder what is different with tashtalk and LT2USB? Do you have a particularly complex network topology with multiple AT routers?

@NJRoadfan does this sound familiar to you?

Anyhow, please do file an issue ticket with the GitHub project and we can take it from there!

twelvetone12 · Feb 13, 2024

Done!

slipperygrey · Feb 15, 2024

Thank you!

If someone wants to track it, the ticket in question is https://github.com/Netatalk/netatalk/issues/719

What we've figured out so far, is that the issue is caused by enabling the "-seed" switch on a single network interface. The fixes we have in mind are: 1) have atalkd bail out early in this state and 2) flesh out the documentation to make it clearer that "-seed" should only be enabled when using atalkd with two or more network interfaces.

slipperygrey · Feb 16, 2024

@ironborn65 I have prepared a "netatalk/netatalk2:test" docker image on Docker Hub that has some refactoring and added error checking to the entry script. If you have a moment to spare, I would appreciate if you could test it on your Synology NAS and let me know how it behaves.

The code is in this branch if you want to look at it: https://github.com/Netatalk/netatalk/pull/721

ironborn65 · Feb 22, 2024

Hi mate and thanks.
Sorry for being late with the test.

But nope, it still does not work.

root@netatalk-netatalk21:/mnt/afpshare# ps -ax
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash /docker-entrypoint.sh
37 pts/0 S+ 0:00 afppasswd -a ironborn65
38 pts/1 Ss 0:00 /bin/bash
44 pts/1 R+ 0:00 ps -ax

logs:

netatalk-netatalk21
date,stream,content
2024-02-22T00:34:08.645169621Z,stdout,Adding user `ironborn65' to group `users' ...
2024-02-22T00:34:08.644962415Z,stdout,Adding new user `ironborn65' to supplemental / extra groups `users' ...
2024-02-22T00:34:08.255856636Z,stdout,Not creating home directory `/home/ironborn65'.
2024-02-22T00:34:07.246243063Z,stdout,Adding new user `ironborn65' (1000) with group `ironborn65 (1000)' ...
2024-02-22T00:34:06.592315047Z,stdout,Adding new group `ironborn65' (1000) ...
2024-02-22T00:34:06.592015356Z,stdout,Adding user `ironborn65' ...
2024-02-22T00:34:05.909403797Z,stdout,*** Setting up users and groups

I hope this helps

slipperygrey · Feb 22, 2024

@ironborn65 Thanks for testing. Have you tried waiting several minutes after starting the container and then see if AppleTalk and AFP services are accessible locally and remotely?

One possibility is that it’s just the logging framework on the NAS that gets stuck on the heredoc context, making it look like the container is stuck when in fact the daemons are starting up. Both atalkd and afpd can take quite a long time to start up fully.

slipperygrey · Feb 25, 2024

@ironborn65 A new version of the "netatalk/netatalk2:test" image is available now.

Among other things, this introduces a new env variable "INSECURE_AUTH". If you set this to non-zero (e.g. "INSECURE_AUTH=yes"), the entry script will skip the afppasswd step, and use the Clear Text UAM instead of the Random Number UAM with afpd. This should bypass the point where the script seemingly hangs on your NAS.

If you can try this out, we should be able to tell pretty quickly if the logs from the startup sequence continue beyond that point and you get a working container.

ironborn65 · Feb 26, 2024

slipperygrey said:
@ironborn65 A new version of the "netatalk/netatalk2:test" image is available now.

Among other things, this introduces a new env variable "INSECURE_AUTH". If you set this to non-zero (e.g. "INSECURE_AUTH=yes"), the entry script will skip the afppasswd step, and use the Clear Text UAM instead of the Random Number UAM with afpd. This should bypass the point where the script seemingly hangs on your NAS.

If you can try this out, we should be able to tell pretty quickly if the logs from the startup sequence continue beyond that point and you get a working container.

Hi @slipperygrey
the netatalk/netatalk2:test process does not start, I can see it from ps -ax

When adding the new parameter INSECURE_AUTH the netatalk process starts as expected, but it stops just after:

*** Removing old locks

stdout