Are org.netatalk.Metadata xattrs ever valid on client-side macOS files?

[JDLH]

I recently had a bad problem with my macOS client hanging when I tried to copy some files and directories from there to a server running Netatalk. I narrowed it down to a file, .DS_Store, which was present in some of the directories. This files each had an extended attribute ("xattr") named org.netatalk.Metadata . If I deleted that xattr, the files and their directories did not cause macOS to hang.

As far as I can tell from my investigations, Netatalk adds the org.netatalk.Metadata xattr to server-side files in order to store certain AppleDouble metadata. These xattrs are only needed on the files stored in the server file system. I suspect that Netatalk would not send them to clients. But these files are years old, they have migrated from client to one server to another server to another client. It is quite possible that at one point, they were copied directly from a file server's file system directly to a client, bypassing Netatalk.

I am tempted to prevent future problems by deleting an org.netatalk.Metadata xattr from every file on my client computer's file system. If any are visible from the client view of files on the server, I'd like to delete those xattrs also. But I'd like to be sure I won't delete any xattrs which ought to be there.

So, are org.netatalk.Metadata xattrs ever valid on client-side macOS files?

And, are they ever valid in the client-side macOS view of files delivered via AFP on a Netatalk server? If Netatalk adds such an xattr to a server-side file, for its own purposes, will it let the client see and delete that xattr? And if so, does any data loss result from the client deleting it?

For what it's worth, this is what the extended attribute in question contained:

% xattr -pxsl org.netatalk.Metadata  "/path/to/my/notes/_.DS_Store_hangs_AFP+Finder_2025-03-06"
org.netatalk.Metadata:
00000000  00 05 16 07 00 02 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 08 00 00 00 04 00 00  |................|
00000020  00 9A 00 00 00 00 00 00 00 08 00 00 01 62 00 00  |.............b..|
00000030  00 10 00 00 00 09 00 00 00 7A 00 00 00 20 00 00  |.........z... ..|
00000040  00 0E 00 00 01 72 00 00 00 04 80 44 45 56 00 00  |.....r.....DEV..|
00000050  01 76 00 00 00 04 80 49 4E 4F 00 00 01 7E 00 00  |.v.....INO...~..|
00000060  00 04 80 53 59 4E 00 00 01 86 00 00 00 08 80 53  |...SYN.........S|
00000070  56 7E 00 00 01 8E 00 00 00 04 20 20 20 20 20 20  |V~........      |
00000080  20 20 40 10 00 00 00 00 00 00 00 00 00 00 00 00  |  @.............|
00000090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000160  00 00 28 50 65 00 28 50 65 00 80 00 00 00 29 C1  |..(Pe.(Pe.....).|
00000170  34 E1 00 00 00 01 00 00 00 00 00 00 00 00 C4 BE  |4...............|
00000180  96 00 00 00 00 00 3E AF 5C 5D 00 00 00 00 FE FF  |......>.\]......|
00000190  1E                                               |.|
00000191

It looks to me as if this extended attribute is 401 bytes long. And what I see in Netatalk source code, atalk/adouble.h#L129-L135, that this structure should be 402 bytes long. I did see a message in my Netatalk server's log,

Mar 04... afpd[65958] {ad_open.c:801} (error:ad): ad_header_read_ea("/server/path/etc/.DS_Store"): short metadata EA

So maybe the content of this xattr is corrupt (short by 1 byte), and maybe that caused Netatalk to react in a way which in turn caused my macOS client to hang. But diagnosing that is not terribly important to me, if I can confidently delete such xattrs from all my client files.

By the way, I have had my most important digital files on servers, delivered by Netatalk to AFP macOS clients, for decades. I use Netatalk in this way every day. My deepest thanks to everyone who has worked on this software, for all the value they have delivered to me. Thank you!

[NJRoadfan]

They are not used for any purposes by a client, so it can be safely removed. The extended attribute contains AppleDouble formatted data for FinderInfo and various internal Netatalk CNID database information for a given file.

Is ea = samba set? That would explain the off by one byte ea error. What version of Netatalk is running on the server? Some additional hardening of the handling of "private" server-side extended attributes was done for 4.1. One shouldn't be able to copy an extended attribute called org.netatalk.Metadata to the server at all. Testing with a macOS client, this resulted in an "unable to copy extended attributes" error with Netatalk 4.1.2 and aborted the entire file copy operation. I suppose this should silently fail (server should ignore the client's request to copy the Netatalk EA vs. sending an access denied error) as the error isn't very descriptive on what EA is causing the copy to fail.

[JDLH]

[org.netatalk.Metadata extended attributes] are not used for any purposes by a client, so it can be safely removed.

Thank you for the answer: "no". That gives me some confidence to delete all my client-side org.netatalk.Metadata xattrs, whether or not they are of a correct length.

What version of Netatalk is running on the server?

I am running version 3.1.13 of Netatalk. This is incorporated in my file server's software. It is not easy to upgrade Netatalk separately, and the vendor has deprecated Netatalk and will be removing it in the future, sadly.

Some additional hardening of the handling of "private" server-side extended attributes was done for 4.1. One shouldn't be able to copy an extended attribute called org.netatalk.Metadata to the server at all.

That is good to know, but it is not the behaviour of my server. I just checked a file on my server's file system which has an org.netatalk.Metadata xattr. My Netatalk server presented it via AFP to the client as a file complete with that xattr, which I could list from the client side. This is curious. If the Metadata xattr is for Netatalk's server-side use, I would expect it to suppress the xattr when it presented the file to the client. In any case, that particular xattr was the correct 402 bytes long on both the server's file system and in the client's view of that xattr.

Is ea = samba set? That would explain the off by one byte ea error.

I assume you mean in afp.conf? My server's file /usr/local/etc/afp.conf has no mention of "ea" or "samba".

However, these files are 5-15 years old. They have been copied forward from server to upgraded server over the years. The current server offers its file system via AFP and SMB and NFS. I can choose which to use when I connect. I could connect via multiple protocols at once. It is quite possible that I copied some of these files either via SMB, or directly from the file server's file system via scp, at some point in the past. There is no reason to be confident that I have only accessed these files via my current server's current version of Netatalk.

[NJRoadfan]

Old versions allowed clients to overwrite or delete the private metadata. I thought this was an oversight, but comments in the code indicate this was intentional! The only thing that was suppressed was showing the org.netatalk.Metadata EA when listing extended attributes. I too thought this was a problem, so started introducing restrictions to prevent a client from directly modifying this data.