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