• 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

slipperygrey

Well-known member
If it helps, I tried using macippi on my pi 3b and ran into lots of issues with netatalk in general. It just does not like any pi older than a 3b plus. Guessing we are running into the same problems with it.
What kinds of errors did you experience with Netatalk on the older Pi? I have a hard time believing that Pi hardware would be a limiting factor, unless there's something proprietary about the network interface / stack or something like that.

From JAG's description above, it sounds like afpd itself is running fine since it's possible to connect to the AFP share over TCP/IP. It's atalkd (AppleTalk daemon) that's erroring out.
 

Johnnya101

Well-known member
I have no idea, just that it wouldn't start up. Here is the log file. This is with the older netatalk that's included with MacIPpi, NOT the new fork.
 

Attachments

  • syslog.txt
    505.6 KB · Views: 3

slipperygrey

Well-known member
I have no idea, just that it wouldn't start up. Here is the log file. This is with the older netatalk that's included with MacIPpi, NOT the new fork.
This might be the pertinent error:
Code:
Jan 28 10:44:15 localhost netatalk[516]: Starting Netatalk services (this will take a while): atalkd: zero interfaces, exiting.

I think it means that atalkd wasn't able to detect which network interface it should be using. Similarly to the advice above, this is where you can try to modify atalkd.conf (which may be in /etc/netatalk/atalkd.conf) and specify the interface, e.g. eth0 etc. See the file itself for a few syntax examples, and 'man atalkd.conf'.
 

mactjaap

Well-known member
On older Pi Netatalk Johnnya101 and myself tested Netatalk 2.2.5. Atalk didn’t start. It gave an severe error and won’t run. Not sure what happening.
Best test would be to compile this new fork and test on a older Pi. I’m missing the time for now to do it. So anybody with a Pi 1 or so please test.
 

cheesestraws

Well-known member
Illegal instruction

Pre-3 Pis are ARMv7 except for the first generation which were ARM11s IIRC (ARMv6), newer ones are ARMv8, IIRC. So software compiled for a newer Pi will not necessarily work on an older one. So this is less to do with atalkd itself and more to do with the architecture it's been compiled for, I think.

(edit: 'pre-3 except the first generation' of course means 'the second generation'. I promise I can count.)
 

Johnnya101

Well-known member
Pre-3 Pis are ARMv7 except for the first generation which were ARM11s IIRC (ARMv6), newer ones are ARMv8, IIRC. So software compiled for a newer Pi will not necessarily work on an older one. So this is less to do with atalkd itself and more to do with the architecture it's been compiled for, I think.

(edit: 'pre-3 except the first generation' of course means 'the second generation'. I promise I can count.)
That was tried on a 3B. Is that considered newer?
 

mactjaap

Well-known member
A
Yep. So you'll need to run a binary compiled for the actual CPU you want to run it on, I expect. This isn't anything to do with netatalk itself and is about how netatalk is compiled.
Ahhh. Thanks! Confusing. A lot of software is just working. But good to know. Will make a MacIPRPi with this new repository… but need some time.
 

slipperygrey

Well-known member
@mactjaap Using a Netatalk 2.x release won't solve the "illegal instruction" issue per se. You may want to consider distributing the source code in your package, and have a shell scripts that configures, compiles, and installs Netatalk (and other software)! This way, you can support any ARM version pretty much.
 

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.
 

NJRoadfan

Well-known member
Regarding the GS/OS folder date bug, you can add a conditional checking afp_version >= 30 for the change_mdate = 1 line. If I have time tonight, I'll submit a revised patch.

Does the icon resources bug appear upstream in 3.x?
 

cheesestraws

Well-known member
First, I want to note in this thread as well how much I appreciate the work you're doing to integrate community patches and especially to liase with upstream netatalk to try to get long-standing stuff fixed. This is impressive stuff.

lost their custom icons

Do you mean custom icons as in icons pasted into the Get Info window, or custom icons as in 'the icons from the BNDL, as opposed to generic application/document icons'?
 

NJRoadfan

Well-known member
I submitted a PR that corrects the GS/OS problem. Testing the bug exposed another possible problem though. Netatalk is exposing the date stamps in UTC to pre-AFP 3.0 clients. I think the date stamps have to be in the server's local time as per the AppleShare docs. I really need to test this with the IIgs and AppleShare 3.0 to see what it's behavior is.
 

NJRoadfan

Well-known member
This is the commit that changed the date stamp logic and follows AFP3.0 specs. I have yet to find the PDF mentioned in the source.

 

slipperygrey

Well-known member
Regarding the GS/OS folder date bug, you can add a conditional checking afp_version >= 30 for the change_mdate = 1 line. If I have time tonight, I'll submit a revised patch.

Does the icon resources bug appear upstream in 3.x?
I tested with the netatalk arm64 3.1.12~ds-8 apt package on the same system and could not reproduce the bug. Files are copied over intact. However, the method of storing meta data has changed entirely between Netatalk 2 and 3 (.AppleDouble vs. OSX style ._* resources) so it's not surprising that the two behave differently.

I submitted a PR that corrects the GS/OS problem. Testing the bug exposed another possible problem though. Netatalk is exposing the date stamps in UTC to pre-AFP 3.0 clients. I think the date stamps have to be in the server's local time as per the AppleShare docs. I really need to test this with the IIgs and AppleShare 3.0 to see what it's behavior is.
Thanks for the patch! I've merged it and submitted it upstream as well. Good job tracking down the code change to a 2002 (!) commit there.

What is the concrete negative effect from the date stamp being in UTC for older AFP clients? That the ultimate time stamp of the copied file ends of as UTC instead of the system's time zone?
 

slipperygrey

Well-known member
First, I want to note in this thread as well how much I appreciate the work you're doing to integrate community patches and especially to liase with upstream netatalk to try to get long-standing stuff fixed. This is impressive stuff.
My pleasure entirely! I couldn't have gotten this far without your contributions and encouragement! Now let's just convince the maintainers to cut a release and start having it trickle down to Ubuntu and elsewhere where the netatalk2 package has been broken for years. Hopefully we can make this happen before the end of #MARCHintosh. :)

Do you mean custom icons as in icons pasted into the Get Info window, or custom icons as in 'the icons from the BNDL, as opposed to generic application/document icons'?
I meant the latter. Sorry for the ambiguous language.
 

NJRoadfan

Well-known member
AFP3 clients always assume the server stores files with UTC, so adjusts the timestamp on files accordingly based on what the client's timezone is set to. Older clients like the IIgs have no concept of timezones, so they just store the timestamp to whatever local time is. The problem is when you copy a file over with an old client and then use a AFP3 client. The old file's timestamp is going to be off by your timezone offset on the new client!

Basically its the same problem timelord has with local vs. UTC times.

I found the AFP3.0 PDF file referenced and compared what was in there vs. Inside Macintosh - Networking Chapter 9. The documented modification date logic hasn't changed between 2.x and 3.x, just that netatalk never implemented it correctly before! The only change is server time is UTC on 3.x and local time in 2.x.

That being said, copying files from a OS X client to a netatalk server does NOT change the copied files "date modified" datestamp to the server's current time. I need to test a AFP2.x Mac client with an unpatched netatalk build and see how it handles the dates. This may be a GS/OS bug. The AFP spec says the client is supposed to store the offset between the client's time and the server's time and adjust things accordingly.
 
Top