Steve1985

Bump

I am using several containers with a VPN (wireguard) server to mask my public IP. This works great. However i wanted to add a reverse proxy to my setup and stumbled across using container names to configure this. Sounds good. But some containers use wg0 network and others use a different network. I have tried adding a second network with docker network connect my-net my-nginx That does work the containers can now ping each other on their container name. However it no longer uses the VPN server's IP for outgoing connections. Is there a way to use 2 docker networks together but still have the VPN IP address as the public IP of that container? So for example: nzbget uses both wg0 and <customerdockernetwork> as its network while routing traffic over the VPN and using the external IP of the VPN. After hours of fiddling tweaking and reading posts and watching youtube i am stuck on this. Hope someone can point me in the right direction

I have added a USB C ethernet dongle to my server. it’s recognised and i can configure it. However it does not appear under “Interface rules”. does this mean a USB device cannot act as a “main nice eth0” alltogether or is this an issue with the server recognising it or a driver issue. it also shows under tools—->system devices so there doesn’t seem to be an issue with it. it’s getting a IP through DHCP which i can’t ping and if i plug in a cable only in this dongle i can’t access the internet or my own network. So would the only use for a USB dongle be to bridge it to a VM? i am planning to run pfsense on this so i thought i’d add some extra nics to it before it do that. But trying to get my head around network settings and UNraid

This is interesting. If i boot straight into tje GUI the uptime is now almost 2 hours. slowly increasing the load by starting docker apps and still stable. too early for conclusions but it looks that the NUC only likes UNraid if it boots into GUI for some weird reason since version 6.11

That’s what i was asking. It’s 30 degrees out my brain is only working on half capacity. found it and put GUI as the default. thanks for the suggestion. Let’s see if this makes a difference. there’s a 11th gen nuc on the way but delayed in shipping. Hopefully it won’t have the same issues

Ah interesting. How does one do this?

Not if the server (NUC) is headless in a rack. As i said the place where it’s normally is in a rack with only ethernet and power connected. sure i could connect a keyboard and a screen while it’s in the rack but before i do that i’d like to make sense of it. Plus it wouldn’t look nice and mess with OCD 😅

Updated the BIOS last week. So this is the latest version available. Does it make sense a issue like this happening ONLY whrn not booted in GUI mode?

Hi @JorgeBThank you and apologies for the late reply. Had to park this for a week as life got in the way. I have upgraded to 6.12. Result is almost the same but this time not a reboot anymore but the nuc just goes unresponsive. Light is still on but there is no response to ping. except when it’s setup in my office. I have it setup there now and it stayed stable overnight. The difference is in the office there is a screen/keyboard/mouse plugged in and i boot into GUI mode. In the rack where it’s supposed to sit it’s booted without the GUI and the only thing that’s plugged in is power and ethernet. any other suggestions? I am stuck at 6.11 now at least from the GUI so now i have to go through the process of manually going back to 6.10.

@JorgeB Thanks for the reply. I have started logging to the Synology and the flash drive. Explored both logs. But nothing stands out (as predicted). I did check some other things. The NUC gen 8 officially supports 2400mhz RAM. I ordered 2x 16GB as a upgrade a while back and it turns out it's 3200mhz. It was from a shop that specializes in intel NUC and only sells them and its parts and this was specifically sold to me for the gen8 so i am a bit surprised. Could this cause such weird issues? And why would it not happen on 6.10.x but from 6.11.x only? The reboot loop has now turned to no more being a loop. I lose ping replies and the web GUI but the unit doesn't reboot anymore. The screen just goes blank. So as a test i've put back the old RAM that runs on 2400mhz and is 2x 8GB. I am still baffled by these issues that only happen on 1 location. The only thing that's different is no keyboard/screen/mouse connected and the port on the switch.

As requested by Limetech support added diagnostics. annabelle-diagnostics-20230604-1111.zip Yesterday the box was stable for 8 hours. This was at another location because i needed a screen to update the BIOS. Now back in its regular location back to the reboot loop. Only physical difference is there's no mouse/keyboard/screen connected.

OK based on some other topics (that were about Ryzen cpu's actually) tried to update the BIOS of the Intel NUC. updated again to 6.11.x about 1 hour ago and so far it's been stable. So for anyone coming here through google experiencing issues with a intel NUC and unraid 6.10+: Update the BIOS to the latest version: BECFL357.86A.0092.UEFI This seems to help.

OKay. tried again. This time 1. stop array 2. run update 3. reboot Result: Reboot loop got worse. Unable to load webinterface. Unable to SSH (connection refused). Ping shows it's up for a while then goes down again so back into a reboot loop but without even able to load the webinterface to revert back Any ideas? From 192.168.1.87 icmp_seq=1158 Destination Host Unreachable From 192.168.1.87 icmp_seq=1159 Destination Host Unreachable From 192.168.1.87 icmp_seq=1160 Destination Host Unreachable From 192.168.1.87 icmp_seq=1161 Destination Host Unreachable From 192.168.1.87 icmp_seq=1162 Destination Host Unreachable From 192.168.1.87 icmp_seq=1163 Destination Host Unreachable 64 bytes from 192.168.1.6: icmp_seq=1164 ttl=64 time=1027 ms 64 bytes from 192.168.1.6: icmp_seq=1165 ttl=64 time=2.94 ms 64 bytes from 192.168.1.6: icmp_seq=1166 ttl=64 time=1.95 ms 64 bytes from 192.168.1.6: icmp_seq=1167 ttl=64 time=1.72 ms 64 bytes from 192.168.1.6: icmp_seq=1168 ttl=64 time=2.20 ms 64 bytes from 192.168.1.6: icmp_seq=1169 ttl=64 time=1.93 ms 64 bytes from 192.168.1.6: icmp_seq=1170 ttl=64 time=1.90 ms 64 bytes from 192.168.1.6: icmp_seq=1171 ttl=64 time=2.12 ms 64 bytes from 192.168.1.6: icmp_seq=1172 ttl=64 time=2.24 ms username@Dell:~$ ssh root@annabelle ssh: connect to host annabelle port 22: Connection refused Update: So the above was caused by the config file returning back to default port 80 and ssh being disabled again.

Thanks. Do i reboot without the array starting by ticking the "safe mode" box? This is a new flash drive so i went through that all already based on a previous forum post about the same topic. I just didn't try the upgrade again because life got in the way of this hobby for a while 🙂 If I upgrade to a 6.12.rc version can i still revert back to 6.10.x?