"Invalid argument" error when "creating metadata EA" (OpenWRT, netatalk 3.1.18) #974
Comments
|
Related to #368 ? |
|
Can you please share the contents of your afp.conf file? Also, if you have the opportunity, try the bleeding edge |
|
Sure. Here goes. Not much there. Thank you very much for taking a look. I have I'll look into using the repo's head for a build... might take a while for me to learn how to tweak OpenWrt's package Makefile to pull that version of the code and not use a tagged commit. |
|
In case it helps... this is how it the build is configured (I think I enable(d)-debugging on last build hoping it would give me something else to look at but I don't know what to look for). So: |
|
I agree that there's nothing in that afp.conf to explain the issue. What I can tell so far is that something bugs out when filesystem extended attributes are being set. Are you able to read and write EAs manually to an arbitrary file? e.g. by using setfattr and getfattr. This test would tell us that your file system has this capability. |
|
Some EA stuff is getting written. (netatalk.Metadata values are all different - truncated them for readibility). Attributes seemingly can be set on a new file: And this didn't work, either because I don't know how to use this (probable) or something is not supported: I get the same behaviour in Ubuntu so it doesn't seem to be a quirk with OpenWrt attr utilities. Edit: regarding setfattr, problem is me. Needs the "user" moniker both in Ubuntu and OpenWrt. This works: |
|
Does it have any relationship with this previous log entry? Maybe something gets messed up if there is no data to begin with. I don't quite understand what the code is doing but will take another look. |
|
Adding more log statements to code to try figure out where EINVAL is first assigned. Don't know yet (if ever), but...
Not sure I'll find what is setting |
|
Adding an That way if something throws an error to I appreciate that OpenWrt is a bit of a niche, and that I'm probably one of the last three people ever that might want to use netatalk to support Time Machines on it for pre-SMB, obsolete MacOS on Macs that can't be upgraded. Not asking for a fix unless this is something you think would benefit everyone, but just your opinion on how much of a terrible idea this is. I can add it as a patch to the OpenWrt Makefile and I'm good to go if you think this holds water. |
|
yes, errno is indeed a global variable. Maybe not the best design decision, but it’s what we have right now. :) let me take a look closer at your patch tonight and make up my own mind if it’s a good idea or not. To facilitate the code review and triaging, would you mind filing a pull request with the code change? FWIW you’re not the first person who wants to use netatalk on openwrt… see: and, at this particular point in history, netatalk is arguably the superior FLOSS choice over Samba for macOS file sharing, if you value transfer speeds. We have a core user base that stick with netatalk for this reason. |
|
As a side note, there is another workaround you could potentially try: configure netatalk to store meta data in AppleDouble dot directories rather than filesystem EA. The afp.conf option is see also the manual: https://netatalk.io/stable/htmldocs/afp.conf.5 in fact, I would be curious to know if this bypasses the error or not. Would give us another indicator where the actual issue lies. |
|
Thanks!
|
|
Note to self: Get openwrt up and running in a VM for testing. https://openwrt.org/docs/guide-user/virtualization/virtualbox-vm |
|
Compiling for OpenWrt can be a bit of an art. I suggest you download the x86 SDK. netatalk is no longer available in the packages directory. I pulled the package definition from version 21.x. I can post the tar file somewhere if you want it (make file, config file, and patches). I've asked to be the new maintainer so it can be put back on. I'm cross-compiling for an ipq806x, so that is the SDK I am using instead of x86. Should make no difference. SDK works well and allows to build the netatalk package. The package definition and an updated Makefile for the package with the 3.1.18 reference is needed. Once the package is compiled, scp-ing it to the running vm and running There is no UI module for netatalk so all configuration needs to be done via ssh. Makefile change in package in case you pull the package from 21.x feeds: (That's an update to the PKG_HASH, VERSION and RELEASE |
|
Thanks for the friendly guide. I'll play around with it this coming weekend. As a side note, since you're aiming to potentially package netatalk for openwrt, we are in the process of transitioning to Meson as the primary build system, rather than traditional autotools and makefiles. A quick googling suggests that openwrt has support for the Meson build system. In short, Meson is a lot faster and simpler to work with. Most configure options are named the same but with a |
|
Once there is a tarball available that relies on Meson we can throw it at the build system to see what gives. Might need to reformat or rewrite the package's Makefile for it to Meson the netatalk build. Happy to try that out. |
|
No difference with With a patched version Patching What I ended up doing is patching I'll try to track down where that I lost the package definition files required for building in OpenWrt SDK. Don't know what the difference may be but now the build also depends on libevent. That may be part of the reason why the previous patch stopped working. Which also makes me think... maybe OpenWrt is doing something unexpected during |
|
@APCCV A stable 3.2.0 release is now available. Do you think it would be possible to upgrade your setup to this version and evaluate how it performs on your system? This release contains two specific patches that address EA metadata handling, namely: #513 and #575 I would be very curious to learn if you're seeing different outcomes with this version! |
|
@rdmark It works! Just adjusted the OpenWrt package Makefile to pick up 3.2.0 and it works. That means the build still uses automake and not meson. Can look at that later. So far I have not been successful to get the package accepted back on OpenWrt. I'll update the PR with this version and try again. |
|
@APCCV Yippie! Thanks for testing, and for working through the issue with us. As a technical note, Netatalk 3.2.0 is now cleaning up "invalid" EA metadata when it encounters it, so you may see similar messages in the future in rare cases when the metadata is actually somehow bad (from Netatalk's perspective). However, it should only appear once for a file or dir. If you see repeated messages for the same file or dir, it means that something is creating EA metadata that isn't "Netatalk compatible". If this starts occurring for you, please file a new bug here and we'll look into it! Using the Autotools build system is totally fine, for the lifecycle of the 3.2.x release series. The only thing you miss out on is the bundled SSL provider, which is only relevant if you lack a compatible SSL provider in OpenWRT (namely OpenSSL 1.1 or LibreSSL). But we of course would love you to try out our fancy new build system, because it is more user friendly and blazingly fast. :) Closing this ticket for now. |
|
Seem to have a Time Machine backup stuck on cleanup with this endlessly in logs: |
|
Nvm... it snapped out of it. |
|
If you run into reproducible bugs, don't hesitate to file a new issue ticket, or start a discussion |
Describe the bug
Attempting to revive the netatalk package for OpenWrt. Using OpenWrt v23.05.3 on ipq806x (arm_cortex-a15_neon-vfpv4) hardware.
Tried to use netatalk 3.1.11 existing packages for older OpenWrt versions and also built new with netatalk 3.1.13 - 3.1.18. Behaviour is identical for all netatalk versions tried out. Using a ext4 fs.
Client is MacOS 10.13.16. Goal is to use Time Machine but issue described below occurs even with non-TM write (copy file through Finder).
This could well be an issue outside netatalk, but here goes.
Client able to connect. Client able to list files on share. However, on attempt to write a file to the share, file is created, zero length. Client reports "error -50" and operation fails.
Log:
Looking at code, I could not locate where EINVAL error is generated for this case. Log show where error is being thrown, so patched temporarily to ignore the error.
Everything seems to be working fine with this, but clearly this is not a solution. Where is the EINVAL coming from?
To Reproduce
Install netatalk packages on OpenWrt (requires some creativity as the package is no longer available for latest OpenWrt versions - trying to fix that).
Finder, Connect to Server, afp:// target, connect, Copy file from HD, paste to share.
Expected behavior
File gets written with content. Refer to patch above to bypass error.
File EA should be written too... I am not sure that is happening if error is ignored but have no way to verify.
What is generating the EINVAL error?
Environment
Config:
Logs
No longer have rest of log but at that point damage is done. With temporary hack above things seem normal afterwards.
Additional context
If it is a crash, please attach a stacktrace.
The text was updated successfully, but these errors were encountered: