Netatalk 4.0 - Future-proofing Apple File Sharing

[MacinJosh]

FWIW, the extension mapping existed in netatalk 2 as well, but it was hidden away in the obscure config file "AppleVolumes.system"

Can you elaborate what the @eadir situation is all about? If you have terminal access to the system, you can use xattr to try setting and getting EA from individual files. Some examples in f.e. https://github.com/Netatalk/netatalk/issues/2089

As a container user, you may be pleased to hear that I pushed v4.3.0 to Docker Hub earlier today! The compressed image size has been reduced to 37MB from 145MB (amd64).

Hopefully you didn't mind that I removed Spotlight and ACLs from the container feature set.

It seems Synology saves metadata in a separate process into these @eaDir folders, which drives users nuts based on some googling. I don't think it impedes Netatalk at all, come to think of it. Looks like Synology doesn't have xattr installed, but I don't need to investigate further.

Sweet, I'll give 4.30 a go at some point. I wouldn't miss Spotlight or ACLs.

Just set up timelord. Omg, my PB540C is happy as it has no PRAM battery. Now to install PRAM Auto-Restore.

Cheers.

 

[slipperygrey]

When in doubt about your filesystem's capabilities, set the "ea" option to the default "auto" (which when editing afp.conf directly means not setting it at all). This way, netatalk will check if the host OS filesystem can handle xattr and turns on filesystem EA if the check succeeds.

I'm glad to hear that you discovered timelord! It really makes it a breeze to get a fleet of old Macs keep the time without bothering with the buggy timedate CDEVs in really old system software, and PRAM batteries.

 

[treellama]

I have lost data with filesystem EA before. You have to be very careful when copying it to other volumes, rsyncing, zipping, etc. It will lose it.

 

[NJRoadfan]

@MacinJosh A2SERVER is being updated to incorporate Netatalk 4.x. Its been a long process (particularly because of the EA support and conflicts with ciopfs), but its getting there.

With regards to Synology and extended attributes, it appears that the Disk Manager software is storing them in a semi-hidden folder called @eadir instead of natively inside the file system.

 

[MacinJosh]

When in doubt about your filesystem's capabilities, set the "ea" option to the default "auto" (which when editing afp.conf directly means not setting it at all). This way, netatalk will check if the host OS filesystem can handle xattr and turns on filesystem EA if the check succeeds.

I'm glad to hear that you discovered timelord! It really makes it a breeze to get a fleet of old Macs keep the time without bothering with the buggy timedate CDEVs in really old system software, and PRAM batteries.

I have lost data with filesystem EA before. You have to be very careful when copying it to other volumes, rsyncing, zipping, etc. It will lose it.

Thanks for the advice and warning. I think I'll play it safe and just turn on AD since xattr doesn't seem to be a command when I SSH into the Synology.

@MacinJosh A2SERVER is being updated to incorporate Netatalk 4.x. Its been a long process (particularly because of the EA support and conflicts with ciopfs), but its getting there.

With regards to Synology and extended attributes, it appears that the Disk Manager software is storing them in a semi-hidden folder called @eadir instead of natively inside the file system.

Good to know. Thanks for confirming this. I think I have this in a good place now.

 

[MacBrian]

Since updating my Netatalk Docker container to 4.3 I'm no longer able to connect from Mac OS 7.5. If I enable INSECURE_AUTH it works again. Is it possible to configure the UAM List in Docker compose?
Another quick question. Is it possible to configure a Login Message as well?

Thanks.

 

[slipperygrey]

Since updating my Netatalk Docker container to 4.3 I'm no longer able to connect from Mac OS 7.5. If I enable INSECURE_AUTH it works again. Is it possible to configure the UAM List in Docker compose?
Another quick question. Is it possible to configure a Login Message as well?

Thanks.

Thank you for the feedback!

You're absolutely right, I accidentally caused a breakage while refactoring the container entrypoint script. This should bring back RandNum auth without using INSECURE_AUTH:

docker: Bring back the RandNum password creation by default by rdmark · Pull Request #2338 · Netatalk/netatalk

In a previous refactoring, running the afppasswd tool got put behind the INSECURE_AUTH flag; this brings it back to the default configuration again to unblock Classic Mac OS usecases

github.com

Would it be sufficient to have a login message at the global level? This would be easily achieved:

docker: Expose Classic Mac OS login message option by rdmark · Pull Request #2339 · Netatalk/netatalk

A new $AFP_LOGIN_MESSAGE environment variable sets the login message read by Classic Mac OS, as a global option

github.com

Regarding uam list, you have the option of enabling $MANUAL_CONFIG and manage all options directly. You can do a bind mount to /usr/local/etc/afp.conf to have a persistent afp.conf. Would this be an option for you?

 

[MacBrian]

Thank you for the feedback!

You're absolutely right, I accidentally caused a breakage while refactoring the container entrypoint script. This should bring back RandNum auth without using INSECURE_AUTH:

docker: Bring back the RandNum password creation by default by rdmark · Pull Request #2338 · Netatalk/netatalk

In a previous refactoring, running the afppasswd tool got put behind the INSECURE_AUTH flag; this brings it back to the default configuration again to unblock Classic Mac OS usecases

github.com

Would it be sufficient to have a login message at the global level? This would be easily achieved:

docker: Expose Classic Mac OS login message option by rdmark · Pull Request #2339 · Netatalk/netatalk

A new $AFP_LOGIN_MESSAGE environment variable sets the login message read by Classic Mac OS, as a global option

github.com

Regarding uam list, you have the option of enabling $MANUAL_CONFIG and manage all options directly. You can do a bind mount to /usr/local/etc/afp.conf to have a persistent afp.conf. Would this be an option for you?

It all sounds perfect to me. Thank you very much

 

[NJRoadfan]

Thanks for the advice and warning. I think I'll play it safe and just turn on AD since xattr doesn't seem to be a command when I SSH into the Synology.

The xattr command is macOS specific. On Linux you can use getfattr and setfattr.

 

[slipperygrey]

It all sounds perfect to me. Thank you very much

The PRs have been merged! These changes will be included in the next stable release (aiming for some time next week.)

 

[MacBrian]

The PRs have been merged! These changes will be included in the next stable release (aiming for some time next week.)

Looking forward to it. Your excellent work with Netatalk is highly appreciated

 

[MacBrian]

I can confirm that the updated Netatalk Docker container works like a charm. Authentication works from Mac OS 7.5 as well as the Login Message.

Thanks again

 

[slipperygrey]

Good stuff, thanks for reporting back. A stable release will follow shortly. There are no other functional changes in this intermediate version apart from the Docker parameters.

 

[MacinJosh]

The xattr command is macOS specific. On Linux you can use getfattr and setfattr.

I see. Those don't work either.

 

[saybur]

I'm trying to add files into a Netatalk share manually via the console. Each has a dot file (._) associated with it. The dot files seem to be well formed, 'addump' shows an AppleDouble format with reasonable looking data to my untrained eye. However, running 'dbd' on the share after the files are added gets a "Bad AppleDouble" data response for each file. I've tried setting ea=ad and moving the dot files to appropriately named entries in an .AppleDouble folder, which stops the original error but starts generating CNID id mismatch errors instead.

Before going further I wanted to see if any of what I'm trying to do is supported behavior or if I'm just missing something obvious, removal of the various megatron tools makes me wonder if there is some other approach I'm just not finding in the docs. I did try 'ad' but it failed with errors about bad home directory paths (which aren't involved here, I have home dirs disabled in afp.conf).

System is Debian trixie running the build of 4.2.3 from the repo. The share is empty apart from the files I'm trying to add; files are the three images buried in the .pax.gz inside the NetBoot9.dmg provided by Apple.

 

[slipperygrey]

@saybur The ad toolsuite is meant to solve this exact problem, but as you've noticed it's terribly buggy. The one known workaround is to carry out the commands with the exact user that owns the shared volume root dir on the host. You can try chowning it to your main user and try again.

I tried to fix the "bad home directory" bug a while ago but it seems to originate deep in the vfs (virtual filesystem) module of libatalk which is too abstract for my brain to comprehend.

 

[saybur]

The one known workaround is to carry out the commands with the exact user that owns the shared volume root dir on the host. You can try chowning it to your main user and try again.

Thank you! I'll give that a try later today and report back.

 

[NJRoadfan]

In theory, you should be able to put both the file and the matching ._ file into the share and it'll "just work", minus the filetype/creator (netatalk doesn't copy the FinderInfo from the ._ file to its metadata extended attribute). You don't need to run dbd for that anymore like with netatalk 2.x, as afpd should see there is no CNID entry in the database and automatically add the file. With all the security hardening done with the AppleDouble handling code, I wouldn't be surprised if something broke somewhere.

 

[NJRoadfan]

OK, the lack of a Netatalk metadata EA is the problem, do the following with your files after you extract them:

ad set -t dimg -c ddsk "Applications HD.img"
ad set -t dimg -c ddsk "NetBoot HD.img"
ad set -t chrp -c tbxi "Mac OS ROM"

Also, the pax utility that comes with Debian has really weird file permissions problems extracting that archive..... yikes. Is there some secret to doing that correctly?

 

[saybur]

@slipperygrey I definitely see the bugginess, ad has some weird behavior. It gets quite unhappy if [Homes] is not defined for one thing. Setting equal permissions on source and destination unfortunately did not work, it emits the following (partial) error for ad cp -R ~/NetBootInstallation /srv/netboot and minor variations of the same:

{netatalk_conf.c:1973} (error:Default): getvolbypath("/srv/netboot"): no user home share defined in configuration

Along a segmentation fault. Trying on individual files without '-R' gives similar messages. When you define [Homes] (with path = afp-data and basedir regex = /home) it instead gives this:

{netatalk_conf.c:2001} (error:Default): getvolbypath("/srv/netboot"): path does not match basedir regex "/home"

Moving NetBootInstallation under ~/afp-path then trying ad cp -R or ad mv generates "Error opening adouble" but if you use copy then move it works fine. Sadly, as soon as you try to move it to /srv/netboot you get the error about home directories again.

OK, the lack of a Netatalk metadata EA is the problem, do the following with your files after you extract them

These commands return without error when the files are under ~ but not /srv/netboot (same error there about not matching basedir regex). Unfortunately I don't see any change in addump output and a subsequent dbd still shows "Bad AppleDouble" data. With log level default:debug set I see stuff being emitted but nothing seems to has a reference to metadata, it just looks like noise about CNID lookups.

Also, the pax utility that comes with Debian has really weird file permissions problems extracting that archive..... yikes. Is there some secret to doing that correctly?

I've been using 7z, which produces a folder set to rwx for user, rw for group, and r for other; the files are rw/r/r. I did do a SHA1 when I first started messing around and pax was producing the same file signatures FWIW.

Easy workaround here (and what I did last time I needed to do this) is spinning up an OSX virtual machine and just uploading the files. I'd prefer an "on the server" approach if it's available (I'm updating my NetBoot instructions and was looking for something simple to inline there) but if ad isn't in a good state I certainly don't want y'all wasting maintenance time for something this simple. I was mainly hoping I was just being dense and missing an obvious command.