• 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

ironborn65

Well-known member
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

Well-known member
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.

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!
 
Last edited:

ironborn65

Well-known member
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:

1707819978414.png
 

Attachments

  • 1707820017982.png
    1707820017982.png
    102.7 KB · Views: 3

slipperygrey

Well-known member
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

Well-known member
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

Well-known member
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:

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

Well-known member
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

Well-known member
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

Well-known member
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!
 

slipperygrey

Well-known member
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.
 

ironborn65

Well-known member
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
 

Attachments

  • 1708562318651.png
    1708562318651.png
    19 KB · Views: 2

slipperygrey

Well-known member
@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

Well-known member
@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.
 
Top