QMoney

Sure enough, that is NGINX Proxy Manager... I've been running it for quite a while and never had the issue before. What's odd, is that I've never set a limit on it's memory, but I am seeing that it is my only container that is allocated less than the max 62.58 GB of ram. It looks like it only has 1 GB to work with, which I can now see probably comes from the extra parameters that must have been included in the template from the app store of "--memory=1G --no-healthcheck". These appear to be pretty standard parameters, as seen in this post. Thanks for the guidance, you're a gem! I'm thinking I should mark this solved since we know what container it probably is, and it's possible that it is known to potentially go on a run with memory hence the limiting parameter. If it happens again, I'll go to the container support forum or github. Let me know if you have any other suggestions. I did a restart after I saved the diagnostics, haven't had an issue with it since, but I will keep an eye on this container and poke around forums when I can. Thanks for catching that! I do need to figure it out. I probably could just disable IPV6... but I think I need to fix the subnet for ipv6. It's hard to find times to shut down docker and fiddle with this stuff. I was messing around for a while working out some issues with the IPV4 aspects of vlans, and want to challenge myself to get better with ipv6. I very courteous bow and a tip 'o the cap to you! Thanks!

Fix common problems gave me an out of memory error warning, which directed me to a recommendation to make a post here and include diagnostics. This is the first time I have ever received the warning. My RAM usage is sitting at 18% of total available, and I have never seen it near 100% (I have 64 gb which is generally well above my needs). I have not experienced anything in particular to be an issue, although I did recently have to re-build my docker image. That was following an unclean shutdown, which I could not find any way to avoid. SSH, direct access and the power button were unresponsive to start a clean shutdown. I have had that happen once before, although I have no reason to think this is related. Since this rebuild, I have noticed that the docker window is frequently slow to load, but is working fine other than that issue. tower-diagnostics-20251003-1449.zip

Thanks! It has been working like a champ since deleting the 3 lines. I want to keep the multiple NICs so I can isolate tagged vlan traffic from the untagged port and offload a bit of noise from my main line. I know that the last 2 entries were required because each fixed a problem immediately, it's just the first of the three I'm not sure about. It's the 1st one below. I don't think it was needed vlan if the VLAN is only for container access: I have not had an opportunity to do a restart and see if it needs fixing. I took a copy of the interface and console versions of the routing tables for when I do. I'm trying to do some research on linux routing tables. I don't think it needs to be very complicated for unraid but some of the automated entries make it look a bit more complicated than it needs to be. It is not intuitive though.

Thanks everyone (@MiguelBazil@rmp5s and others I won't bug with tagging) I was helped by this thread... eventually. I ran into this issue wile switching my home network to a DIY opnsense router, WAP, vlans, etc. I also added a 10G SFP+ card to my unraid server. So many variables... I couldn't connect to my unraid server across VLANs. I thought it was a network vlan issue at first. I had a really tough time figuring out where my problem was because I had to reasonably assume that my lack of understanding of my brand-new opnsense and vlan tagging on switches adventure was my problem. I was wondering if I had collision issues, firewall, all sorts of stuff I knew little about. Eventually, after a ton of self-doubt and trying to fix firewall issues, I narrowed down that it was not an inter-vlan issue. I could iperf3 across vlans between other devices, and I could even ping unraid from other vlans, but the iperf3 would only send a packet or so then nothing when trying to connect to unraid from specific vlans. I noticed that the only VLAN connections to the server having issues were those VLANs I had created connections for to Unraid on my other 2.5G NIC (I was already having issues, probably the same reason, when I had all the vlans running through the same 10G nic). After a LOT more time and frustration, and thanks to this thread, I was able to successfully 'fix' the issue by deleting some routing table entries. However, @MiguelBazil now has me worried that this is something I will need to do every reboot. Right now, I have a fix (maybe) and more questions: 1. Deleting some of the ipv4 entries related to the gateways for the vlans (which I shouldn't need), appears to have allowed traffic to my primary bridge as expected. 2. I had to use the CLI to delete the 'default' one, which did not immediately fix traffic. I don't know for sure if this was required. 3. I don't know enough about routing tables to know what should be there and what shouldn't. Or if there's any other stuff there I don't need. 4. Will I need to re-do this after every reboot? 5. How will I ever know that my routing table is correct?