Netatalk 4.0 - Future-proofing Apple File Sharing

[scj312]

Interesting. The error here is that netatalk wasn't able to detect a usable network interface for DSI (AFP over TCP). Was networking functioning at all in the container in that state? For instance, exec into a shell in the container and try pinging other server etc. This might be something worth trying the next time you experience this.

Hopefully it doesn't happen again, but I will definitely do some more poking around before restarting the container next time. Thanks!

 

[scj312]

Interesting. The error here is that netatalk wasn't able to detect a usable network interface for DSI (AFP over TCP). Was networking functioning at all in the container in that state? For instance, exec into a shell in the container and try pinging other server etc. This might be something worth trying the next time you experience this.

Well, it has already happened again. A few things I have been able to confirm:
1. The container still has network access (I can ping both inside and outside of the network via docker exec)
2. In this state, I cannot see Netatalk via AppleTalk
3. My modern Mac which has an AFP share already mounted is not interrupted. I can continue to browse and open files on the share. However, I can't see the listing of shares in the Finder to open a new one.
4. I see multiple instances of afpd when running ps aux in the container:

PID   USER     TIME  COMMAND
    1 root      0:00 {entrypoint.sh} /bin/bash /entrypoint.sh
   21 root      0:00 cupsd -C /etc/cups/cupsd.conf -s /etc/cups/cups-files.conf
   23 root      0:06 atalkd
   27 root      0:00 papd
   29 root      0:00 timelord -l
   31 root      0:00 a2boot
   32 root      0:12 netatalk -d
   34 root      0:00 /usr/local/sbin/cnid_metad -d -F /usr/local/etc/afp.conf
   37 pluto     0:07 /usr/local/sbin/afpd -d -F /usr/local/etc/afp.conf
   44 root      0:00 /usr/local/sbin/cnid_dbd -F /usr/local/etc/afp.conf -p /mnt/afpshare -t 10 -l 5 -u pluto
  190 nobody    0:00 /usr/local/sbin/afpd -d -F /usr/local/etc/afp.conf
  191 root      0:00 /usr/local/sbin/cnid_dbd -F /usr/local/etc/afp.conf -p /mnt/globaltalk/PurrTopia Web ƒ -t 7 -l 5 -u nobody
 7455 root      0:00 ping 1.1.1.1
 7468 root      0:00 ping 10.0.1.1
 7474 root      0:00 ping 10.0.1.14
 7517 root      0:00 /usr/local/sbin/afpd -d -F /usr/local/etc/afp.conf
 7518 root      0:00 ps aux

FWIW, the only change I have made to my Netatalk setup recently has been to add some additional shares, but I haven't made any other changes (well, other than upgrading the container the other day). Here is my config: https://gist.github.com/dremin/5deaffb336828b0e9283ca7aa5fe90e3

 

[rdmark]

Could you try ejecting the connected AFP mount from the modern Mac, and then try connecting again to netatalk in the container through the Connect to Server dialog: Press Cmd+K in Finder and connect to "afp://ip-address-of-docker-host"

It would also be interesting if you could run "nbplkup" inside the container, while an old Mac is also running and connected to the network. This would tell us to what extent AppleTalk routing is working.

Do you remember which netatalk version you were running before, which was stable?

What host OS are you running this container on?

 

[scj312]

Could you try ejecting the connected AFP mount from the modern Mac, and then try connecting again to netatalk in the container through the Connect to Server dialog: Press Cmd+K in Finder and connect to "afp://ip-address-of-docker-host"

It would also be interesting if you could run "nbplkup" inside the container, while an old Mac is also running and connected to the network. This would tell us to what extent AppleTalk routing is working.

Do you remember which netatalk version you were running before, which was stable?

What host OS are you running this container on?

Connecting via IP address did not work in the failed state.

nbplkup in the failed state can still see my jrouter instance running on another host, I forgot to go turn on a Mac:

For versions, 4.0.4 was stable until it wasn't--that's the version I was on when I originally posted about the issue. However, it had been very stable for me until recently. The docker host is running Ubuntu Server 20.04.3 and Docker 20.10.21.