Netatalk 2.3.0 available

[Mk.558]

Here's what I've written so far.



Seems like libcups2-dev libavahi-client-dev libgcrypt20-dev are specified there: is the Berkeley DB not required anymore?

I have no idea what bootstrapping does for tarballs: I poked around the web and most of it seems to be related to bootstrapping the OS, which isn't the same thing as here. I will probably update the text a bit (still considering whether I should make a dedicated tutorial for it, but since it's changing soon anyways...) but it'll look very similar to that in the next release. I do know that I followed the 2.3.2 instructions and my PC took at least an hour to install all those dependencies, of which I found out later were unnecessary (like autoconf).

 

[NJRoadfan]

bootstrapping creates the "configure" script that you run in the instructions above. Normally it is not required with the release tarballs as they include the configure script already. Netatalk 2.4 & 3.2 is slated to offer the option to build with the Meson build system. It is likely GNU autotools/automake will be deprecated and removed in the future.

Berkeley DB is still required as it is needed to run the CNID database for AFP.

 

[slipperygrey]

@Mk.558 I've added descriptions of all packages on the wiki page now, and broke them down under mandatory/optional headings. Among the optional features, I personally would say Zeroconf (Avahi) / PAM / CUPS are very useful.

If you have an older Debian system (v11 or earlier) you should also install OpenSSL 1.1 to get the DHX and RandNum UAMs for Classic Mac OS. Debian v12 and later ships with OpenSSL 3.0 which isn't compatible with the older cryptography anymore.

The other features have much more narrow use cases. Probably relevant only to the 1% of users who want to do complex deployments with many users...

 

[slipperygrey]

@Mk.558 Regarding your draft, if I may provide feedback on two specific points you're making:

1. Netatalk 3.x irrelevancy

Netatalk 3.x (and 2.x) can happily do Time Machine backups of APFS file systems. In fact, you get better transfer speeds than with Samba (which is one reason we still have a dedicated 3.x userbase). Of course, the threat of the AFP client going away from macOS in the future is still looming large. This is what I would suggest you call out as the reason for irrelevancy.

2. LocalTalk driver

The loss of the LocalTalk driver in the Linux kernel has little impact to the Netatalk project. Few PCs have physical LocalTalk interfaces anyways. Losing the AppleTalk kernel module would be a bigger blow, but luckily it is still kept alive (thanks to some hard working community members here!)

 

[Mk.558]

Thank you for the feedback. I swapped LocalTalk for AppleTalk and reworded the Netatalk 3.0 similar to what you wrote.

Looks good on the wiki. If I may point out however, the code text is really small. It could be that I'm on 1440p, but it definitely seems harder to read than the surrounding text.

 

[slipperygrey]

Thanks for the feedback on the text size. Let me try to tweak the CSS stylesheet a bit. The entire website structure and layout originates in the mid 2000s so it’s definitely optimized for old school screen resolutions and DPI.

 

[slipperygrey]

@Mk.558 The font size of body text has been set to 100% up from 80% across the site. Please let me know if this is easier on your eyes now.

The font sizes on the top navbar and left rail menus are kept at the old 80% font size however, to not completely break the pixel perfect layout.

 

[Mk.558]

Looks good to me. The brown coloring on the text provides better contrast. That table of contents has me slightly envious -- I haven't been able to make a nice tidy ToC that remains clean across different browsers

The Guide was specifically designed to be compatible with 1024x768 displays, so it's a little stuffy by modern standards, but I'm not worried.

 

[slipperygrey]

That TOC is really just a div with absolute positioning! The original author of this layout did a good job making a simple but effective design. The only major change I’ve made is to remove the original PHP code and instead create a custom Python script that builds all pages from html templates (basically just fragments of pure html). It’s a surprisingly useful homebrew CMS.

I think the old school look of your website, and the netatalk one, makes absolute sense for the subject matter.

 

[MacBrian]

I have installed the Netatalk 2.3.x Docker container on my Synology NAS but I see an issue with the reported diskspace on the AFP share.
I can log on to the server from my SE/30 but there are only a few MBs available even though there should be several gigabytes.
I do not see the issue when I log on to the server from my modern Mac with macOS 14.

Have anyone seen this before and know a solution?

 

[pl212]

Not an expert on Netatalk, but I think there are situations where System 6-7 can’t handle extremely large volume sizes on remote servers. IIRC there was a flag in Netatalk to mask or otherwise hide the actual size of the volume to avoid situations like this…

 

[slipperygrey]

@MacBrian You can try the "options:limitsize" AppleVolumes option, and see if that makes a difference. Older AppleShare clients made assumptions about shared volume size based on the file system limits in HFS which will wreak all sorts of havoc on file size calculations when too large numbers are passed to the client. The limitsize option will tell the client that the disk size is always 2GB, as a workaround.

I would be curious though what will happen to the reported available space when you add files to that shared volume, and if the Finder will error out when it "runs out" of space (as per the faulty calculations.)

See also https://netatalk.io/oldstable/htmldocs/AppleVolumes.default.5

 

[Mk.558]

I don't know if limitsize actually works or not. Regardless of how big the volume actually is, it seems to still report it (in older SSW versions) as 2047.9MB available and in Mac OS 9 it just reports the full size. However, volsizelimit, does work. I'm told that limitsize is a bit of a hack.

I think the old school look of your website, and the netatalk one, makes absolute sense for the subject matter.

A lot of website content these days is bloated beyond recognition, but the real reason is that I can't be bothered to make it any more complex than it already is, and yours is just like that. (See here for a proper example.)

 

[MacBrian]

@pl212 , @slipperygrey , @Mk.558 thank you for taking your time to answer.

Unfortunately it does not seem to work for me. I’m not really able to copy anything to the share, no matter how small the file is. Finder will always tell me that there is not enough space. I can create a folder though.

I’m running Mac OS 7.1 with Open Transport 1.3.1 and AppleShare Client 3.7.4. I’m connecting to the Netatalk server via IP since it’s not visible on AppleTalk.

This is my YAML configuration:

version: "2"
services:
netatalk:
image: netatalk/netatalk2:latest
network_mode: "host"
cap_add:
- NET_ADMIN
volumes:
- afpshare:/mnt/afpshare
- /var/run/dbus:/var/run/dbus
environment:
- "SERVER_NAME=Netatalk Server"
- "SHARE_NAME=Data"
- "AFP_USER=username”
- "AFP_PASS=password”
- "AVOLUMES_OPTIONS=options:limitsize"
- "ATALKD_INTERFACE=eth0"
- "ATALKD_OPTIONS=-router -phase 2 -net 0-65534 -zone NETATALK"
volumes:
afpshare:

 

[NJRoadfan]

The "limitsize" option works based on the revision of client connecting. A pre-AFP 2.2 client is given a 2GB limit, while later clients are given the correct size.

 

[Mk.558]

Have you tried using volsizelimit? Sharing a volume with a smaller size, such as using a thumbdrive or SD card formatted to have usable space under 2GiB?

Old fashioned AppleTalk, if you can do it, maybe better than relying on AFP over TCP.

 

[NJRoadfan]

I've never had to use the option. File sharing has always "just worked" across various versions of the AppleShare client, on both Macintosh and Apple II. It reports a lower free space value to the earlier clients to prevent that value from overflowing. See screenshots (The "prodos" option limits it to 32MB).

I have run into weird problems with other AFP servers with large drives and old clients. I remember connecting to a PCMacLAN server from GS/OS and seeing junk data (negative numbers) for the "Free" value in Finder windows. I suspect there are other problems with the Docker container seeing that AppleTalk isn't working either.

System 7.1:


MacOS 9.0.4 (AFP 2.2):

 

[MacBrian]

Thanks for all the suggestions.

Tonight I once again started over and created the Netatalk docker image with the exact same YAML file and now it works!

I can copy a 25 MB file to the Netatalk share without other issues than the available disk space is reported incorrectly.

I’ll do some more testing over the next few days. I can’t really explain why it did not work yesterday when it apparently is working now.

Now I just need to find out if it’s possible to use AppleTalk to connect.

Once again thanks for all your help.

 

[NJRoadfan]

If network type host doesn't allow layer 2 bridging, you will likely need to configure your container network type to macvlan in order to use AppleTalk. See: https://docs.docker.com/network/drivers/macvlan/

 

[MacBrian]

@NJRoadfan thanks for the info about macvlan.

Tonight I did some more testing and this was not very uplifting.

A lot of the same files I was able to copy yesterday does not work today. And even more strange some of the files I was not able to copy yesterday works fine today. I can replicate it on both my SE/30 and in BasiliskII.

I'm starting to loose faith in getting Netatalk 2 in Docker to work on my Synology