jzawacki

And one more time. I was already using macvlan with v6.12.4 and have read the release notes about it.

I am using macvlan becuase ipvlan never worked properly. ipvlan wasn't even an option.

Good luck with that. When I attempted to use ipvlan, the entire unraid server had issues talking to the network. I was hoping to no longer be a part of this topic as my server had been running fine for over 6 months without issues. Then, being super dumb, I updated to 6.12.4 and the server kernel panic'd literally the next day. Hopefully, after it finishes a parity check, it'll go back to normal. Fingers crossed.

It do, it's a: 08:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rage 3 [Rage XL PCI] (rev 27)

Hopefully that works for you. I don't even have Virtualization enabled.

Same for me, I couldn't even get the host to be able to update after switching to ipvlan, and I'm not using UniFi. So, I believe, if ipvlan fixes it for anyone, it's because it is stopping the actual cause (one of the dockers?) not to be able to talk to the network. But that's just a guess.

I wish there was a solid answer/fix. For me personally, It had to do with one of the dockers. I installed docker and portainer on my backup server, moved a bunch of dockers to it, and although I still have 9 dockers running full time on unraid, my server uptime is currently 21 days and I can't remember the last time it kernel panic'd. Now, since I'm posting this, it'll kernel panic by the end of the night.

Well, I had to switch back to macvlan due to some network weirdness. unraid had been running for 20 days without issues, but I had some dockers that wouldn't stay connected and it wasn't till I realized that unraid couldn't check to see if there was a version update available, did I blame it on the docker ipvlan setting. Switched it back to macvlan and all the network weirdness went away and the server hasn't kernel panic'd yet, so I'm keeping my fingers crossed.

I'm afraid to post.. cause I don't want to jinx myself, but unraid has been up for 5 days after switching to ipvlan running all dockers except for one (that is known to cause issues). I hope I don't have to post again any time soon.

There is a lot of info here.. so I'm just going to chime in so that I receive notifications as this thread progresses. Not speaking on the cause of anyone else's kernel panics, but mine match a few of these screenshots verbatim. I've been running Unraid for as long as I can remember and running dockers since they were originally introduced. My server has been rock solid this entire time, even after upgrading MB/Proc/RAM, adding 10G NICs, replacing HDDs, etc. Even with 6.9.2, never had any issues. Out of the blue, I decided to upgrade to 6.10.0 and everything went south. Random kernel panics. Obviously, blaming it on the upgrade, reverted to the previous version, 6.9.2 but the kernel panics continued (in hindsight, is it possible that 6.10.0 made changes to the docker configs causing 6.9.2 to continue having issues?). Doing the research, assumed it was hardware related and replaced the MB/Proc/RAM and the kernel panics continued. I noticed that it appeared the kernel panics seem to happen around the time the Appdata Backup/Restore was scheduled, so I started diving into that. Found some errors accessing files, so thought it might be corruption issues. Resolved all that, moved appdata to different drives, on to/off of cache, etc. Turned off all containers and slowly turned them on, one at a time (over the course of a month), to see if I could pinpoint the cause, but nothing was repeatable. Everything appeared to be random. As of two days ago, my server had been running for 28 days with all dockers running without issues. So, when it kernel panic'd the other day, I remove Appdata Backup/Restore, moved everything docker related onto the protected array and it kerenel panic'd that evening. Anyway, latest change I am testing (finger's crossed) is changing the docker setup to use ipvlan instead of macvlan. if that doesn't work, I'm going to plug another NIC in and try using eth# instead of br0 for the dockers that need a static IP to operate properly. PS: I learned of ctop, which is like top for docker containers.. loving it. Wish it was built into Unraid or that Unraid had that information available within the web GUI.

Since PiHole has the ability to track individual devices, I would configured the DHCP server to hand out 192.168.1.3 and a fake IP address for the second IP. Then, on PiHole, make it's upstream DNS custom and give it 192.168.1.4. Then, on LanCache server, give it's upstream DNS as your ISP's DNS or 8.8.8.8, or whoever you prefer. Using this method, you retain all the function of PiHole with the benefit of the LanCache server. Just keep in mind that if DHCP hands out more than 192.168.1.3 as a valid IP address, things might not always work correctly, as windows doesn't use them as primary and if I can't talk to primary, use secondary, it will randomly use either of them depending on how it feels at the time. You may also have to clear the DNS cache on the PiHole if it already knows the real IP address for the services you are trying to cache. James

It's funny you say this. The docker run command is correct, all configured properly, but it doesn't make it into the container, I promise. (IP and path redacted) docker run -d --name='unifi-controller' --net='br0' --ip='1.1.1.13' -e TZ="America/Denver" -e HOST_OS="Unraid" -e 'UDP_PORT_3478'='3478' -e 'TCP_PORT_8080'='6759' -e 'TCP_PORT_8443'='6760' -e 'TCP_PORT_8880'='6761' -e 'TCP_PORT_8843'='6762' -e 'UDP_PORT_10001'='10001' -e 'PUID'='99' -e 'PGID'='100' -v '/REMOVED/unifi-controller':'/config':'rw' 'linuxserver/unifi-controller' But, what I was able to end up doing, is put the docker in a location that is easily accessible via SMB share, manually change the permissions of the system.properties file so I could edit it easily, save the file and restart the docker. Bingo, it's listening on all the custom ports I wanted it to be listening on. debug.device=warn debug.mgmt=warn debug.sdn=warn debug.system=warn is_configured_and_restarted=true is_default=false portal.http.port=6761 portal.https.port=6762 unifi.http.port=6759 unifi.https.port=6760

Apologies if this has been addressed, I saw notes around page 8 of others having issues using custom ports, but I couldn't find a solution. It's unfortunate that so much of this thread is standard UniFi controller support over container support. Anyway, I have been unsuccessful using custom ports for this container as well. I have configured the docker properly, but the defaults are still used. If I go into the container and look as the system.properties file, the port options are all commented out, so I'm not sure how the UniFi controller is supposed to know to use the custom ports. Thanks, James

EXCELLENT FIND! Just as a note, I also had to "fix" the /etc/nginx/sites-available/10_generic.conf you referenced in the link, as mine had the error_log listed twice. I too am now seeing proper "HIT" and "MISS"! Thanks for the info!

I was thinking the same thing, but if all of your DNS servers are running on unRaid anyway, you are basically taking the internet down with unRaid anyway. With that said, I'm still running pfsense on dedicated hardware because I don't trust a docker to not be compromised and your firewall is something important enough to care a little more about than standard dockers. Your firewall is there to protect your network and you would be putting an interface on unRaid directly on the internet. Not really a good idea, IMO.