Netatalk 4.0 - Future-proofing Apple File Sharing

[mactjaap]

Kept on trying and have some succes now!

root@maciprpi:~# afpgetstatus 192.168.178.78
trying 192.168.178.78 ...
Server name: MacBookAir13
Machine type: Netatalk4.0.8
AFP versions:
     AFP2.2
     AFPX03
     AFP3.1
     AFP3.2
UAMs:
     DHCAST128
     DHX2
Signature: 857ef07f5a0e065e8e748025a24e8f9b

 

[NJRoadfan]

I managed to get brew to compile almost all the prereqs on a 4GB mid-2012 MacBook Air running Catalina. It errored out on MySQL and I think one of the things required for Spotlight. It was slow, but didn't take 24 hours. What makes it take so long is the brew scripts insist on running all the test suites that come with the packages!

 

[slipperygrey]

@mactjaap This is on your Monterey Mac? Did you do anything special to make it work?

@NJRoadfan I was on the fence about whether to have mysql as a dependency or not. The formula is noticeably heavy to install even on a 2019 MacBook Air. I might look into making it an optional dependency in a future formula revision.

Could you confirm what the other failing dependency was? Spotlight is disabled in the formula, so it couldn't have been that. (Neither Tracker nor D-Bus works very well in the Homebrew sandbox, in my experience.)

 

[mactjaap]

@mactjaap This is on your Monterey Mac? Did you do anything special to make it work?

@NJRoadfan I was on the fence about whether to have mysql as a dependency or not. The formula is noticeably heavy to install even on a 2019 MacBook Air. I might look into making it an optional dependency in a future formula revision.

Could you confirm what the other failing dependency was? Spotlight is disabled in the formula, so it couldn't have been that. (Neither Tracker nor D-Bus works very well in the Homebrew sandbox, in my experience.)

Yes. I finally managed to get it working.
I had to fix some permissions as you mentioned. I also had to do some extra installs, like MySQL. I will have a look at my history tonight. I’m on the road now so no access to my MacBook.

 

[slipperygrey]

In the next revision of the Homebrew formula, I'm looking to replace mysql with mariadb, which is significantly lighter (as in, less disk space and much quicker to install.)

 

[mactjaap]

In the next revision of the Homebrew formula, I'm looking to replace mysql with mariadb, which is significantly lighter (as in, less disk space and much quicker to install.)

Nice! Thanks for all your good work!

 

[slipperygrey]

If you happen to run Netatalk on a macOS host, some significant enhancements are on the way. This should nearly replicate the functionality of Apple's now deprecated AFP server in macOS.

The big one is that resource forks are now natively stored in the file system as opposed to using "._" AppleDouble files. This works regardless of the filesystem your drive is formatted in, so you can share from APFS, HFS+, or even exFAT drives (the OS handles the AppleDouble translation here).

Next up is FinderInfo is synced with the native filesystem metadata, which appears as com.apple.FinderInfo. Things like the filetype/creator information will now be synced with the host. In addition, storage of extended attributes for macOS (AFP3.2 and newer) clients should now be working properly.

These improvements to macOS interoperability are included in netatalk 4.1.0 which I tagged and released moments ago.

Check out the release notes and grab the tarballs at: https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-1-0

This version will trickle downstream to Homebrew and elsewhere eventually.

 

[slipperygrey]

@Mk.558 It's worth calling out that two features that you requested are in the 4.1.0 release version.

Namely, a macipgw.conf configuration file. And, the new tabbed interface in the Webmin module.

Check the updated macipgw manual page for an example of the configuration file. This allows you to more flexibly run macipgw as a system service.

Also worth calling out is that thanks to the hard work of a new contributor, netatalk 4 runs better than ever on OpenWrt. He even got the OpenWrt kernel patched to make AppleTalk networking functional again. So if you have a compatible device, you can now potentially run the entire netatalk AppleTalk suite, including the MacIP gateway, on actual router hardware.

 

[mactjaap]

Yes. I finally managed to get it working.
I had to fix some permissions as you mentioned. I also had to do some extra installs, like MySQL. I will have a look at my history tonight. I’m on the road now so no access to my MacBook.

This is what I did. I have cleaned it up a little bit.

#brew install
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
sudo chown -R the_current_user /usr/local/var/homebrew
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
brew update

# netatalk install
brew install netatalk # failure
sudo chmod -R 775 /usr/local/Cellar/
# more failures and this helped:
brew install gcc meson ninja xmlto docbook docbook-xsl
brew install netatalk

And it works perfect!

root@maciprpi:/opt/afp-perl/atalk-perl# /usr/local/bin/afpclient.pl "afp://mactjaap:********@192.168.178.78/"

Volume Name                                 | UNIX privs? | Volume pass?
-------------------------------------------------------------------------
mactjaap's home                             |     Yes     |     No

root@maciprpi:/opt/afp-perl/atalk-perl# /usr/local/bin/afpclient.pl "afp://mactjaap:********@192.168.178.78/mactjaap's home"

afpclient mactjaap@192.168.178.78:mactjaap's home/> ls
-r--------   1 mactjaap staff             7 Jan  9 13:22 .CFUserTextEncoding
-rw-r--r--   1 mactjaap staff         10244 Jan 10 22:09 .DS_Store
drwx------   2 mactjaap staff             0 Jan 12 00:02 .Trash
drwx------   4 mactjaap staff             0 Jan 11 23:59 .bash_sessions
drwxr-xr-x   3 mactjaap staff             0 Jan 10 01:20 .config
drwx------   4 mactjaap staff             0 Jan 10 09:31 .ssh
-rw-------   1 mactjaap staff          1394 Jan 10 22:51 .viminfo
drwx------   4 mactjaap staff             0 Jan 10 01:38 Applications
drwx------  60 mactjaap staff             0 Jan 12 00:47 Desktop
drwx------  12 mactjaap staff             0 Jan  9 13:44 Documents
drwx------   6 mactjaap staff             0 Jan 12 00:45 Downloads
-rw-r--r--   1 mactjaap staff             0 Jan 10 09:55 Installing
drwx------  87 mactjaap staff             0 Jan 10 13:46 Library
drwx------   4 mactjaap staff             0 Jan 10 01:24 Movies
drwx------   3 mactjaap staff             0 Jan  9 13:05 Music
drwx------   4 mactjaap staff             0 Jan  9 18:56 Pictures
-rw-r--r--   1 mactjaap staff             0 Jan 10 09:55 Pouring
drwxr-xr-x   5 mactjaap staff             0 Jan 10 01:30 Public

 

[Mk.558]

...

Great stuff! The only complaint I have left then would be whether macipgw could be examined to figure out why it doesn't work as smoothly (? is there such a thing?) on other types of TCP traffic. Like FTP.

 

[slipperygrey]

Great stuff! The only complaint I have left then would be whether macipgw could be examined to figure out why it doesn't work as smoothly (? is there such a thing?) on other types of TCP traffic. Like FTP.

Please remind me: Were you able to get around to trying a more recent FTP client (late 90s-ish) that can do passive mode? I don't think it's feasible to use active FTP over a NAT'ed bridge, but passive FTP should theoretically work fine.

 

[Mk.558]

... No. Fetch 3.0 has a PASV setting that I tried out with macipgw and I didn't find any change.



It probably actually works, but I'm not sure how exactly to monitor ftpd with OS X (probably via the log, idk) to check what the connection type is and what ports it's using to see if it's doing it properly. macipgw should be able to pass through normal TCP / UDP traffic without many issues, because FTP works on Apple IP Gateway and IPNetRouter just fine. But people have complained about MacIP before back in the day, and I've seen discussions in the early days about "issues" and "figuring this DDP/IP situation out".

 

[slipperygrey]

If you start a new GitHub Discussions thread, we can try a little troubleshooting again, if you like.

I bet the "DDP/IP situation" referred to the now-removed IPDDP Linux kernel module. It conflicted with macipgw operation.

 

[NJRoadfan]

Apple IP Gateway uses proxy ARP with a pool of configured IP addresses in the Ethernet network's subnet, thus no IP masquerading/NAT is involved. IPNetRouter is a full blown router with NAT that supports port forwarding and likely has it setup for FTP by default. The Linux nftables firewall can be setup for port forwarding if needed: https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers

FTP is not NAT friendly and it is not secure. At this point its easier to just use the built-in python web server to serve a given directory.

 

[Mk.558]

IPDDP I think came after MacIP. CAP also had various "stuff" going on with it because to be frank it was a mess back then and took some time for things to get figured out. When I'm referring to DDP/IP I'm thinking of stuff like this, there were a few other documents and early drafts/proposals/email exchanges talking about the problem.

I'd argue that FTP should be figured out because on a Plus or SE, web browser choices are ... not great, slow and you can't upload files. Security point is.... Fair but let's be honest if we were trying to maintain a AES256 encryption level, certificates, public/private key shenanigans on these old machines we'd be a little out of our minds. Even SSHv2 on a 68030 is awful for transfer speeds and there's only one program that can do SSHv2, and it's not even that great. Only one program supports SCP, and it doesn't do SSHv2.

 

[NJRoadfan]

...or, given that the machine has an AppleTalk connection, just use Netatalk's AFP server to transfer the files.

 

[slipperygrey]

Yeah I was going to say: you already have a powerful file sharing protocol at your fingertips there thanks to Netatalk.

 

[Mk.558]

There is no contest from my side about Netatalk being good, but that doesn't invalidate the problem with either macipgw or NAT not working correctly that means that certain services don't work properly.

What if I want to FTP to a remote server? A Plus can't run OpenTransport, so AFP over TCP won't work, which means the literally only thing to that can remote xfer both ways is FTP.

That leaves Telnet (...no...), SSHv1 with NiftyTelnet (doesn't work on a 68000, and SSHv1 doesn't make sense to use), SMB (doesn't work on a 68000 either), or NFS (...maybe...it was slow on a SE/30, and I'd much rather use FTP over NFS).

 

[twelvetone12]

I used macipgw + LocalTalk + Netatalk (+ AirTalk to have IP over DDP over IP for full redundancy) and in my experience it works very well. FTP is super tricky since in active mode you need to open a port to the world and forward it on all routers: your main router and the computer with macipgw. I used to run an FTP mirror locally on the pc doing MacIP but Fetch was ultra slow, so at the end I just mirror whatever I need via AFP, it not as convenient as having my plus directly browse and FTP server but in my experience it is much stabler and faster.

 

[JAG]

I'm working on getting Netatalk 4 up and running and have a couple questions:

1. Is it still the case that Mac OS hosts do not have support for atalkd to share files to older Macs (System 7 etc)?

2. My server has a 250GB SSD. How are we limiting volume sizes for older machines? Using the "legacy volume size =Y" option or making a 2GB disk image and mounting as a loop device and then sharing that? This is a VM so I could go and make a new 2GB HD and just attach it but not sure the best way to do this if it were a physical machine with only one storage device.