• 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.

Yet Another Netatalk 2.2 Fork

NJRoadfan

Well-known member
Here is the missing AFP3.0 PDF docs referenced in the source.

I have to perform the following tests:

With AppleShare 3.0:
Test file copy from GS/OS client to server and see if date modified changes.
Test folder copy from GS/OS client to server and see if date modified changes on copied files and folders.
Test file copy from Mac System 7 client to server and see if date modified changes.
Test folder copy from Mac System 7 client server and see if date modified changes on copied files and folders.

With netatalk:
Test file copy from Mac System 7 client to server and see if date modified changes.
Test folder copy from Mac System 7 client server and see if date modified changes on copied files and folders.
Do the above with and without the patch.

It seems like in the Apple IIgs world and likely the Macintosh world, timestamps are retained when you copy a file from one volume to another. In the UNIX world, it appears the modified date on the newly copied files is set to the current date-time. It should be noted that when I copy a file to a server with a AFP3.x client (macOS Catalina), the timestamps are retained.

The UTF and timezone offset issue is completely separate, but could use some looking into.
 

Attachments

  • AFP3.0.pdf
    1.9 MB · Views: 6

NJRoadfan

Well-known member
Initial testing with AppleShare 3.0 shows that timestamps are retained when files are copied from GS/OS to the server. Also tested a System 7 client against netatalk with the patch, no ill effects. I'm guessing this is a GS/OS behavior only bug. Looking at the AppleShare FST source that is available..... somewhere... shows it calls FPSetFileParams on file creation. This likely triggers the routine in file.c that needed a patch.

I don't know how AFP 2.x Mac clients handle file creation, but they don't seem to trigger a timestamp update. It's likely because Apple II clients have to set special filetype/creator values for files or, its the ProDOS specific attribute creation.
 

elvis

Member
@slipperygrey thank you again for this project.

I run a small project called RetroNAS which aims to try and offer simple ways of installing all sorts of protocols for older computers and consoles (not just Mac focused). We target any Raspberry Pi device, or any computer/VM that can install Debian 11 currently, and have a simple TUI/GUI to install different things.


We've included your Netatalk-2.x fork as well as a basic config, which I've tested and is working very well across three systems:
1) Virtual Apple II GS (via GSport) running GS/OS System 6.0.1 (DDP only)
2) Real iMac G3 running OS 9.2 (DDP and IP both work)
3) Real iMac G5 running OSX 10.5 (IP only)

These all work simultaneously, as do other systems like Windows95 through to 11 inclusive as well as modern macOS builds that can share files with these via Samba pointing to the same disk location (we enable LANman, NTLM, SMB1 and other legacy SMB protocols too for old DOS/Windows machines, as well as things like TNFS for FujiNet, Spectranet, etc on Atari 8bit, ZX Spectrum, etc, and these can all share between each other).

The Netatalk2 documentation is up to date, however the videos linked were from prior to switching to your fork (I was using Debian packages from older releases prior):

So far so good, and a handful of users trying it out have all reported it working well. But I just wanted to specifically say thank you for, what I consider to be the single best Netatalk2 project around, and keeping this family of protocols alive and well.
 

NJRoadfan

Well-known member
Alright, some more testing of behavior with AppleShare 3.0 shows that it does NOT update the "modified date" on any files when changing their attributes from classic MacOS clients. This is even though Inside Appletalk 2nd Edition says that the "modified date" should change whenever file attributes are changed. The behavior is consistent with local file behavior on both GS/OS and classic Mac OS.
 

slipperygrey

Well-known member
@elvis I'm honored to have done something that's helpful for the RetroNAS project! The service you're providing to the community is very valuable. Thanks for the shout-out on your wiki there.

FWIW, I've been able to connect to Netatalk 2.x AFP shares from both Big Sur and Monterey clients, as long as you enable the DHX2 UAM. What was deprecated in Big Sur is the ability to run an AFP server, I believe, and the ability to connect to one as a client is still there.
 

NJRoadfan

Well-known member
Yes, functionally Netatalk works as expected. AFP3 clients don't muck with the modified date timestamps no matter what, so its likely this bug was never caught.
 

elvis

Member
@elvis I'm honored to have done something that's helpful for the RetroNAS project! The service you're providing to the community is very valuable. Thanks for the shout-out on your wiki there.

FWIW, I've been able to connect to Netatalk 2.x AFP shares from both Big Sur and Monterey clients, as long as you enable the DHX2 UAM. What was deprecated in Big Sur is the ability to run an AFP server, I believe, and the ability to connect to one as a client is still there.
Ah OK good to know, I'll update our documentation accordingly.

And no problem for the wiki mention. The project aims to be very clear that we're not writing new protocols, merely bundling other people's hard work (although recently a new developer has come on board who's writing quite a lot of interesting GUI tools, which has been fun). But acknowledging upstream authors is important to our ethos. So thank you again for keeping this very important project alive.
 

slipperygrey

Well-known member
Bug Alert: Netatalk 2 will fail to create icon resources for classic Mac OS files copied onto the AFPShare when running on 64-bit Linux. On Mac OS 7.5 and earlier, files will still be copied but when you access them from another Mac, you will notice that they have lost their custom icons. On Mac OS 8.6 and 9, the Finder will throw error -50 and refuse to copy the file. Mac OS X / macOS clients are not affected.

This affects all versions of Netatalk based on the 2.x codebase, including upstream Netatalk 2.2, the Netatalk 2.x fork, and the Netatalk-Classic fork.

For now, it is recommended to run Netatalk 2 on 32-bit Linux. I will notify here again once we find a fix for the bug.
False alarm! It turns out to have been a permissions issue all along.
If you're seeing missing icons or Error -50, you need to make sure write permissions are set correctly for the .AppleDesktop dir inside the shared directory.
Basically, the user that you authenticate with needs to have write permissions.

If permissions are indeed an issue for you, as the authenticating user do a recursive chmod in this fashion:

sudo chmod -R 2775 path/to/shared/dir
 

slipperygrey

Well-known member
I'm proud to present a new release from the Netatalk 2.x fork: https://github.com/rdmark/Netatalk-2.x/releases/tag/netatalk-2-220401b

This version constitutes a massive refactoring, code cleanup, plus security and stability improvements.

The primary functional change is that the configure script now enables everything AppleTalk related by default, without having to pass half a dozen parameters. The only recommended parameter is for choosing the install type, e.g. --enable-systemd. See the README.md for more examples.

Another fun tidbit is that I went through and tested all the remaining configuration time features, making small fixes here and there to make them compile cleanly. A few examples that you can enable and play around with:
  • SLP, Server Location Protocol. This was the stopgap measure for service discovery in Mac OS X 10.0 and 10.1, before Zeroconf / Bonjour was introduced in 10.2. It doesn't play well with the Zeroconf implementation with Avahi in Netatalk, so you have to choose one or the other.
  • Quota. If you want to limit the amount of files or storage space that one user can utilize on the server, enable and configure Linux quota! Somewhat useless in this day and age, but kind of a fun thing to mess with.
  • Cracklib. Something you can use with the Random Number UAM. Leverages a database of known weak passwords to warn you when using the afppasswd tool. Again, fairly useless, but entertaining!
Anyways, please try out the release, and report back if you run into any bugs!

PS: the Error -50 issue that I described above was caused by a regression bug that I fixed before tagging the release. You should not have to set any special permissions to the shared dir in most cases.
 

JAG

Well-known member
What system are people compiling this on? I've tried ubuntu 20.04 as well as Debian 11.3 and get the same error each time when I do ./bootstrap (see below). I'm new to making my own Docker images, but I'd like to get a Docker image made where it's a bit less painless to get something up and running.

+ rm -rf autom4te.cache
+ aclocal -I macros
+ autoheader
+ libtoolize --force --copy
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: copying file 'macros/libtool.m4'
libtoolize: copying file 'macros/ltoptions.m4'
libtoolize: copying file 'macros/ltsugar.m4'
libtoolize: copying file 'macros/ltversion.m4'
libtoolize: copying file 'macros/lt~obsolete.m4'
+ automake --include-deps --add-missing --foreign --copy
configure.ac:13: installing './compile'
configure.ac:6: installing './missing'
bin/ad/Makefile.am: installing './depcomp'
+ autoconf
configure.ac:54: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:16033: error: possibly undefined macro: AC_MSG_WARN
+ exit 1
 

NJRoadfan

Well-known member
No problems with Debian bullseye here. Make sure the following packages are installed so the bootstrap script will run.
-autotools-dev
-automake
-libtool
 

JAG

Well-known member
Not working for me. This is on a freshly installed Debian i386 11.3 VM.

Here's an outline of what I'm doing:

Code:
apt install git libssl-dev libdb-dev autotools-dev automake libtool

git clone https://github.com/rdmark/Netatalk-2.x.git

cd Netatalk-2.x

./bootstrap

Fails with the error I listed in post #112. Same if I use an AMD64 VM instead of i386.

I'm sure it's something simple I'm not doing correctly? Pulling the wrong repo? Something to do with it running in a VM?
 

NJRoadfan

Well-known member
Make sure "build-essential" is installed too. Need that for the compilers and header files and I don't think Debian installs that by default. This is the complete list of packages the a2server scripts pull to build netatalk.


Code:
build-essential

libcups2-dev

libssl-dev

libdb-dev

autotools-dev

automake

libtool

libgcrypt20-dev

libavahi-client-dev
 

JAG

Well-known member
Turns out it was a package called "pkg-config" that wasn't installed. After that, it compiles fine and runs.
 

cheesestraws

Well-known member
Turns out it was a package called "pkg-config" that wasn't installed. After that, it compiles fine and runs.

Ahh, I should have thought of that. I've been bitten by that not being installed multiple times myself, and will probably be bitten by it again...
 

JAG

Well-known member
Just some additional follow-up for anyone struggling to get this running.

By default, /usr/local/etc/netatalk/afpd.conf does not have ddp enabled, which does not allow older systems to access shares. Change the -noddp to -ddp and restart the service (on debian: sudo service afpd restart)

When I have changed this on my systems, the atalkd daemon stops loading and I have to add the name of the network device I'm using to the end of the config file /usr/local/etc/netatalk/atalkd.conf. Again, restart the service

Lastly, I couldn't get printing to work despite Cups being up and running. I had to add 'cupsautoadd:eek:p=root:' to the end of the papd.conf file. I only figured this out after digging through the rascsi setup scripts.

That's all for now. Hope this helped someone else. Thanks again for the great job getting this up and running on modern distro's.
 

slipperygrey

Well-known member
Just some additional follow-up for anyone struggling to get this running.

By default, /usr/local/etc/netatalk/afpd.conf does not have ddp enabled, which does not allow older systems to access shares. Change the -noddp to -ddp and restart the service (on debian: sudo service afpd restart)

When I have changed this on my systems, the atalkd daemon stops loading and I have to add the name of the network device I'm using to the end of the config file /usr/local/etc/netatalk/atalkd.conf. Again, restart the service

Lastly, I couldn't get printing to work despite Cups being up and running. I had to add 'cupsautoadd:eek:p=root:' to the end of the papd.conf file. I only figured this out after digging through the rascsi setup scripts.

That's all for now. Hope this helped someone else. Thanks again for the great job getting this up and running on modern distro's.
These are all sound tips, good job figuring this out. While this advice comes a bit late, I've done a write-up on configuring Netatalk over at the RaSCSI wiki that covers these points and others.

Instead of '-ddp' you can also put '-transall' which activates both DDP and DSI (TCP/IP) which can be handy for cross-generational Mac networks.
 
Top