Recent content by scj312

It's possible for cap leakage to result in damaged traces within the startup circuit, given how many caps are there. The place on the logic board to look at is in the area underneath the power supply. Magnification may be required to see any breaks in the traces. It's also possible there is a...

Ah! I wonder if something is not quite right with the afpd restart process--my Mac (modern, using TCP/IP) never disconnects from the mounted AFP share when this happens, and it can continue to read and write from the share during the restart loop (however, if I unmount, then I cannot reconnect)...

Netatalk is the only thing running on that machine using DDP (unless something is hiding :) ). As for the MAC, AFAICT the host MAC is used. I have jrouter running on another machine and it reports the host's MAC for Netatalk's DDP address. Is the sockets number you are referring to host-wide...

Unfortunately, without AppleTalk, netatalk isn't of much use to me :) I'd be willing to test this for a bit, but unfortunately this issue is a bit unpredictable--sometimes it occurs within a day or two, other times it takes weeks. Ah, that naming issue was due to a misconfiguration at the time...

With the debug logging, unfortunately I don't see much of note when the error occurs that initiates the first restart: Apr 13 07:10:14.761241 afpd[74] {volume.c:316} (debug:AFPDaemon): getvolparams: Volume 'Files' Apr 13 07:10:14.761280 afpd[74] {ad_conv.c:298} (debug:end_of_list_marker)...

@rdmark Unfortunately, I seem to be stuck in a restart loop once again: I'll increase log levels so that next time we have something more useful to work with.

Awesome, thanks! It's working great here.

@rdmark I went to update my Docker container to 4.2.0, but noticed that version is not available on Docker Hub; the latest is 4.1.2. Thought you might like to know in case something broke :)

I added `afp interfaces` to my `afp.conf` and haven't seen the issue since! I don't, as my config files are not large or complex enough to warrant this.

Alright, it failed again and this time I remembered to turn on some more Macs! Here is the nbplkup result within the container. I also ran some pings to IPs both on and off the subnet. It looks like everything is fine from a network perspective, so the errors from Netatalk are a bit puzzling.

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...

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...

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

I've been using Netatalk 4.0.x Docker container successfully for quite a while and ran into my first real issue with it today. For some reason, afpd got into a crash loop: Interestingly, an existing AFP connection I had up to it from another machine never disconnected. Did Netatalk...

This is very useful data! I'd also be very curious how the SE's original "squirrel-cage" fan performs in comparison to these axial fans (thermally--we already know the noise situation is not good!)