Possible issue with Zeroconf.

[pbobbenb]

Hi, I have a peculiar problem with Netatalk, well I’m not fully sure if Netatalk is to blame, but I got to start somewhere.
I’m using a program called AutoMounter for macOS to auto mount network shares and that’s where the problem is. If I add the server in question (in AutoMounter) it’s fine and it says it’s available/online but as soon as I add an AFP share (from said server) it switches to saying it’s offline but it does mount it, but only when first added. Restarting AutoMounter and now it can’t mount the share and it says AFP is not available but it is available in Finder and can be mounted from Finder!
(This is with Mount with Bonjour):

Currently the “problematic” server in question is a Mac Mini 4,1 running Ubuntu 20.04.6 with own compiled Netatalk 2.2.9.
Have tried an older version of Netatalk - 2.2.7 and the newest 2.x-230701 and the issue is the same.
Made some tests in a Ubuntu 22.04 VM where I first tried Ubuntu compiled (from apt install) Netatalk 3.1.12 and that works correctly!
So I then tried own compiled Netatalk 2.2.9, 2x-220101 and same issue, then tried own compiled Netatalk 3.1.15 and this time a slight change in behavior in that it now doesn’t say that the server is offline, but that Bonjour is not available, although all versions have been compiled with avahi/zeroconf, at least that’s what the ./configure script output says with ”Zeroconf support = yes”.
If I unselect ”Mount with Bonjour” in AutoMounter it does mount the shares, the VM with Netatalk 3.1.15 says ”online” and the Mac Mini with Netatalk 2.2.9 says ”offline” in AutoMounter, so it seems there is a difference between 2.x and 3.x in regards to zeroconf behavior.
(This is without Mount with Bonjour):

Config command for 3.1.15: ./configure —with-init-style=systemd.
Config command for all 2.x.x: ./configure —enable-systemd —sysconfdir=/etc —with-uams-path=/usr/lib/netatalk.
So, it seems like it has something to do with Zeroconf/Avahi, question is what?
The Avahi version on Ubuntu 22.04 VM is 0.8-5ubuntu5.1.
And on the Mac Mini Ubuntu 20.04 the version is 0.7-4ubuntu7.2.

Have other AFP shares that works fine in AutoMounter with my ReadyNAS Duo (Netatalk 2.2.5) and SynologyNAS DS415play (Netatalk 3.1.12).
The machine trying to mount stuff is an iMac 21,5” with Monterey 12.6.6 and AutoMounter 1.7.2.

[pbobbenb]

Have done some more digging in the Ubuntu 22.04 VM and there afpd -V (3.1.15) clearly says Zeroconf - Avahi but still Automounter says Bonjour not available and can't mount the share, but if I add a afp.service file in /etc/avahi/services then it became available and mounted the share!
Will do some more testing with 2.x, I think I did a test compiling it without zeroconf and having an afp.service file in /etc/avahi/services that didn't make any change, will have to double check though.

[pbobbenb]

Well, as I thought I remembered having "zeroconf - avahi" and afp.service file in avahi or compiling it without zeroconf and having afp.service file in avahi - none of it works with 2.x-230701, so this trick only seems to work in 3.1.15...

[rdmark]

What is the content of your afp.service file?

In 3.1 the netatalk wrapper daemon is in charge of advertising zeroconf, while in 2.2 the afpd daemon handles that. That's the main difference between the two when looking at the code / changelog.

[pbobbenb]

afp.service looks like this on the Mac Mini Ubuntu 20.04 machine and the Ubuntu 22.04 VM is exactly the same except it has Windows as device info.

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=Macmini5</txt-record>
  </service>
</service-group>

[pbobbenb]

Some additional information from AutoMounter logs.
First log is from removing an AFP share, waiting until AutoMounter says it's available/online and then re-adding the same share and then becomes offline and says AFP not available.
AutoMounter.log

Second is from removing an AFP share, waiting until AutoMounter says it's available and then quitting and restarting AutoMounter and then re-add the same share and again the server changes to offline but it mounts the share and says mounted. But as mentioned before, this only works on first try with AutoMounter freshly restarted.
AutoMounter2.log

[pbobbenb]

Well, this is interesting, installed Ubuntu 20.04 in a VM and then compiled Netatalk 2.2.9 and even though it's on a different IP range (10.211.55.x) compared to my other stuff which is on 192.168.1.x it works just fine!

I'm beginning to wonder if pi-hole which I have running on the Mac Mini Ubuntu machine is the culprit somehow...
But that doesn't fully explain why adding an SMB share makes it switch to available and successfully mount that share.
Or why Netatalk 3.1.15 has some issues in the Ubuntu 22.04 VM, which is on the 192.168.1.x IP range.

[pbobbenb]

Well, managed to find the issue (and it wasn't pi-hole) after much tinkering and a re-install and then restore of Ubuntu!
The issue is IPv6, as soon as I turned it off, the server became online and mounted the share!
And works every time after reboot of the machine and restart of AutoMounter.

Question is, why IPv6 should disturb anything?

I'm guessing it has something to do with the ethernet driver for this Mac Mini (Nvidia 320M - MCP89) in Linux...
Because as I mentioned previously, it works fine in the Ubuntu 20.04 VM which has IPv6 enabled and my SynologyNAS also has IPv6 enabled and everything is working fine there.

[rdmark]

Good job narrowing down the triggering factor! Another user has reported trouble with ipv6 (dual stack) so there may be some underlying defect in netatalk code. #181

[rdmark]

@pbobbenb We have done some general improvements and bugfixes since your report. Any chance you can try again with the latest Netatalk v4 release?

[pbobbenb]

Yes, I will have a look...

[pbobbenb]

Hit a bit of a snag with trying Netatalk v4 on my Ubuntu machine which is at 20.04 and it doesn't seem to have the package "tracker-sparql-3.0-dev" but probably can be installed somehow. But I scoured through the documentation on netatalk.io + some other places, but I can't find anywhere what version of different Linux distros that are required/recommended for compiling the new Netatalk v4...

[rdmark]

@pbobbenb Ubuntu 20.04 ships with a much earlier version of the Tracker stack, which should work fine with netatalk. Use apt to search for tracker or sparql. After installation, you can run pkg-config --list-all | grep tracker to get the exact version of the libraries to pass to the netatalk build system.

FWIW, Tracker is only used by our Spotlight feature. If you don't have the Tracker libraries on your system, the netatalk build system will automatically disable Spotlight support and happily compile the rest of netatalk.

But more importantly: the version of the Meson build system that comes with Ubuntu 20.04 is likely too old to build netatalk. A workaround would be to install Meson as a python package, i.e. using python3 pip instead of apt.

We don't maintain a granular support matrix for operating systems and Linux distros. In 99% of cases, Meson is the limiting factor. We require at least v0.61.2. If your system has a supported Meson version, netatalk v4 will also likely be supported.

Our INSTALL.md readme lists the mandatory requirements, for your reference: https://github.com/Netatalk/netatalk/blob/main/INSTALL.md#external-software-dependencies

In conclusion, please find out the latest version of Meson that you are able to install on your system, and we can take it from there.

[pbobbenb]

I managed to compile netatalk v4.1 on the machine (I forgot I had previously tried compiling v4.0, so tracker libs and meson (from pip) was already in place) and then reactivated ipv6, restarted NetworkManager - no issues.

Removed the share and server from Automounter, restarted Automounter, re-added the server and then the share - still no issues, which was an issue before.

So, it seems with this minor testing that the new netatalk doesn't seem to have an issue with ipv6!

[rdmark]

Thanks for testing! FWIW, netatalk's Avahi based zeroconf can get... stuck sometimes. Not sure what causes it, but a reboot of the client often solves the problem.