-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tons of invalid metadata EA ... #992
Comments
It would be helpful to see the actual metadata assigned to the offending files/dirs. F.e. "/mnt/tank/home/stefan/.DS_Store" Compare the use of |
Hi, handling of metadata is a bit different in FreeBSD.
The last two lines print it as hex or stringifyed. |
I found out, that there are directories, that seem to be ok. I got the metadata for one of them:
|
Okay, probably not the most elegant solution.
|
The extended attribute checking to fix the various CVE exploits is a bit too strict. The |
@NJRoadfan Last year we worked through several "invalid metadata EA" reports and made the checking more forgiving in certain areas. A recurring one for directories was 0 length comment I think, which we fixed in https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-1-16. I want to try to dig into these latest batch of reports to see if the offending metadata can be pinpointed, and see if the data is truly invalid and should be cleaned up, or if there are valid cases that currently fail our checks. |
Ah interesting. In the My main concern is that your metadata will become "bad" again (whether a false positive or not) so I would appreciate it if you could keep an eye out for these errors to return again after some usage. |
@sfranzis A stable 3.2.0 release is now available. Do you think it would be possible to upgrade your setup to this version? We have a new manual appendix with build instructions, including FreeBSD, which might be a good starting point for you. When authoring the release notes, I was reminded that we actually have one more fix for EA meta data validation in this release: I have a little bit of faith that the above will resolve your issues! |
Thanks for the new release, but in my case I use it on an embedded system. So currently I see no way to test it. We have to wait until the FreeBSD community has updated their ports and then wait for a new release of XigmaNAS. |
Well noted. I have notified the FreeBSD ports maintainer for netatalk3 about the new release, so unless he runs into some roadblocks the port should be updated shortly. |
The FreeBSD port has been updated to 3.2.0 https://www.freshports.org/net/netatalk3/ |
XigmaNAS also has updated. https://www.xigmanas.com/forums/viewtopic.php?t=2175 |
Thanks for letting us know! Let me close this ticket for now. If you run into new reproducible issues, don't hesitate to throw up a new ticket. |
Describe the bug
I use netatalk on a XigmaNAS embedded system, which is based on FreeBSD.
Tons of "invalid metadata EA this is now being treated as a fatal error" log entries
I had this behavior with netatalk 3.1.14 and now with 3.1.18.
Due to the fact, that it's an embedded system, I cannot easily change versions of netatalk/afpd
To Reproduce
Config file afp.conf:
Expected behavior
no error logs
Environment
Logs
Additional context
I tried different settings I've found in other bug reports, including:
ea = ad (also sys or none)
convert appledouble = no
No change in the behavior
The text was updated successfully, but these errors were encountered: