jdiacobbo

Thanks for the response. I appreciate your assistance in getting this working. Your post makes total sense. I was attempting to troubleshoot my server not appearing in the server browser by using the port checking site but it makes sense that wouldn't work in this instance. I eventually got it sorted. I was trying to copy over a locally hosted game to the sever container to run it there instead and that was the issue. I ended up renaming all the files to the default name servertest and that got it working. Can you confirm that you need to either use the files created by the container or have your files use the same names (i.e. servertest.ini)?

I am trying to get a Project Zomboid server up and running and I cannot get the port to appear available when checking via canyouseeme.org nor can I connect to the server. I've successfully set up port forward before for various ports so I know my router's port forwarding is working. I've installed the container with the default settings and forwarded the ports but its not working. I'm suspecting there is some firewall preventing access from within the container. Any ideas what I'm missing here? Container: Firewall port forwarding rules: Logs showing ports:

I am having this same issue. Have you figured out a solution yet? Out of curiosity, what version of unraid are you on? As a note, I have set up a User Script to run daily to restart the container to hope fully prevent the issue from occurring until I can figure out the root cause.

Is this guide still the recommended way to accomplish running one container through another's VPN connection or is there an alternate method that should be used in 2024?

After updating my docker network from macvlan to ipvaln I have not experienced any more crashing. I think its safe to call this issue resolved at this point. Thank you to everyone for your support in helping me figure out the issue.

It's been about 24 hours since the change from macvlan to ipvlan and there haven't been any crashes. I'll continue to monitor but I'm optimistic this might have been the issue. Sent from my Pixel 8 using Tapatalk

Adding to this, would upgrading to v. 6.12.4 resolve this issue? https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

I attempted this yesterday but lost network access to my Home Assistant VM and couldn't figure out how to properly reconfigure the VM to get network access back. Is it recommended to use macvlan with bridging disabled over ipvlan? What would the pros/cons be for each setup? Is there anything that I should ahve done when switching from macvlan to ipvlan in docker setting? I made the switch and didn't change anything else and everything appears to be working but I don't know if I'm sitting on an issue waiting to appear because I didn't do something when I made the switch. I tried to check out the resources in the help text in that field in the settings but they were general docker docs and I'm not sure how to relate the information to my setup. If I were to go with macvlan with bridging disabled is there a resource you could point me to on how to get proper networking in a VM with that configuration? Sorry for all the questions but my networking skills are my weakest when it comes to server stuff. I'm hoping to come out of this issue better educated and more informed and appreciate all the assistance.

The issue happened again last night. I've attached the syslogs and what was on the screen when I found it down. I don't see anything in the logs this time around. Doesnt appear to be the RAM causing it. Any ideas on next steps? I'm going to try changing from macvlan to ipvlan to see if that might be the cause. Its the only thing I can see in the screenshot that might be the issue. syslog-192.168.0.150-20231219.log

I happen to have a spare set of RAM recently pulled from a working PC. I'll try swapping that in an see if I still have issues. Thanks for the support! *EDIT* Just swapped the RAM. I'll let it run for a few days to see if the issues still appear and provide an update. Thanks again to everyone for the help. Fingers crossed!

Thanks you for taking the time to help out. Networking is admittedly my weakest skill when it come to home-labbing. Could you help me figure out how to make sure bridging is disabled on eth0? Is this a BIOS setting? *EDIT* Would it be this setting here? Also is there anything else I would need to know about making this change? What else this might affect?

Does that lead you to believe that macvlan is my issue and I need to configure ipvlan instead?

After a full server reboot docker was able to come back up so I'm guessing the docker images is OK. Interestingly, before the reboot I wanted to do a scrub on the docker image but the whole docker volume section in the docker settings was missing. After reboot i am able to see it again and running a scrub produced no errors. Also before the reboot I did try to run a scrub on the cache drive and it would abort every time with out running. After the reboot I am able to run the scrub on the cache drive (no errors detected). From what I was reading on other posts this might be either a memory issue or a macvlan issue. Any ideas on what it could actually be? Attaching updated logs and diagnostics. syslog-192.168.0.150_reboot.log tower-diagnostics-20231218-0945.zip

After recreating the docker image I woke up this morning to most (but not all) of my docker images stopped. I tried to restart them and got Execution error Error code 403 Looking at the syslogs I see BTRFS error (device nvme0n1p1): block=7008911360 write time tree block corruption detected I've attached the full syslogs from the last 4 days. *EDIT* Trying to restart Docker gives me this error Docker Service failed to start. syslog-192.168.0.150.log

The syslog server is how I got the attached logs. I just cut it to the part where the issue occurred. Should I post the whole log? Sent from my Pixel 8 using Tapatalk