KFStein

Honestly, I only used unRAID Connect for the Let's Encrypt certificate. That avoids the browser warning messages when connecting or having to put my CA cert in my browser's trust stores; it was just a cosmetic thing and not really needed. Tailscale is a no-go for me, but Wireguard works well for remote access. A few months ago I finally got access to my DNS provider's API, so can now generate a wildcard cert for my internal domain, (I use an internal DNS server for the local network). The certificate stuff is managed on the first unRAID server, but wrote a script on the second server to pull the cert in and (if different then what's installed currently), update the unRAID cert bundle and reload nginx. That looks to be working great and there are no more delays getting to the web UI after a reboot. That's probably not a solution if anyone else has a similar issue, but I'm considering this resolved for my use case.

This happens on both my unRAID servers and started possibly after going from 7.2.3 to 7.2.4, but for sure I started seeing this going from 7.2.4 to 7.2.5 and also 7.2.5 to 7.2.6. Diagnostics for both are attached. urbr1-diagnostics-20260512-0820.zip urbr2-diagnostics-20260512-0638.zip

Looks like it does. I just did a reboot: (Currently at 1295 seconds and going.) (Viewing the server In unRAID Connect.) (Browser error when clicking the link in unRAID Connect.) (SSHing into the server. All Dockers and things are running as well.) (Trying the local IP address.) (Editing the /etc/rc.d/rc.nginx file then running /etc/rc.d/rc.nginx reload.) (Now can get to it with the local IP.)

Yes. However, my questions are: Why does the "connect" URL (e.g. 192-168-1-9.<HASH_OR_SOMETHING>.myunraid.net) stop working for at least an hour after the reboot (site unreachable per Firefox), and Why I have to edit /etc/rc.d/rc.nginx if I want to access my server locally e.g. https://192.168.1.9 or https://unraid2.int.mydomain.com (the latter resolves to 192.168.1.9 via internal DNS)? The rc.nginx script adds the connect URLs as valid destinations (server_name) to the nginx config, but not the local addresses. Maybe the latter is just a byproduct of enabling unRAID Connect? I can't remember the last time I've had to resort to using the local IP/hostname. That did work before without making edits to anything, but perhaps that was before I started playing around with Connect. However, for sure I've done OS upgrades with Connect enabled before with no real noticeable delay in being able to get to the UI using the Connect URL To be more clear on that point, when you do the reboot in the UI, it'll ultimately end up on a page with a "restarting" timer. Usually that counts up to 120 - 240 seconds on my system and then the login form appears. but now it just keeps going for a long time (never personally saw how long, but for sure I let it go a little past 900 seconds once before refreshing the page and getting the "site unavailable" message from the browser). Not scientific, but today that time frame looks to be over 1 hour but under 3.

I just checked and the Connect URL is now working, so somewhere between 1 and 2 hours it seems to be OK. The local IP works IF I edit /etc/rc.d/rc.nginx and on line 308 change server_name ${SERVER_NAMES[@]}; to server_name ${SERVER_NAMES[@]} 192.168.1.9;.

Hm, on one of my servers, I just tried to remove a Docker and the UI just "hung" with the "processing" animation, and when I refreshed the page, I got the Firefox "unavailable" error. I rebooted from the command line and now it's behaving like after the upgrades. I don't really reboot the servers much, so maybe it's a reboot thing and I only saw this due to rebooting after an upgrade. Only right now if I go to unraid.net, I can see the server and "Server Details" works, but when I go to "Server Management" instead of the UI, it gives a link to the unRAID Connect URL (which doesn't work).

For the past few OS upgrades (for sure 7.2.4 to 7.2.5 and then 7.2.5 to 7.2.6), the WebUI is inaccessible for a period of time. I am not sure how long as the first time I tried to debug it for about an hour then went to bed, and the next day it just worked. Same for the latest 7.2.6 upgrade. I can reach the servers using SSH and going through unraid.net via unRAID Connect. But the unRAID connect URL does not work (Firefox gives a "can't connect to server" error). My Dockers and shares are fine, though. When I try access the WebUI using the local IP, nginx gives a "404 not found" error. To get around accessing the local IP, I edited /etc/rc.d/rc.nginx over an SSH connection and manually added my server's IP to the SERVER_NAMES variable. I've reverted that to keep things "stockl", but not something I've had to do in the past. And if I just leave things overnight, the unRAID connect URL starts working again. I am not sure how long that took, but last night and the time before, it was at least over an hour. Any ideas what's going on?

Ugh, except all my Docker containers are gone...

Strange. I copied the img file for the non-starting VM to a different directory under the same /mnt/user/domains directory, and created a new VM using that img as the primary disk, and it started fine.

I have a VM on a cache drive which is two SSDs in btrfs. One of the SSDs seems to have died and the VM that handles DNS and firewall won't start giving a "can't read block backend" error. My whole house is dead to the Internet and am using my phone to write this. Help!

In the process of writing this post I ended up solving the issue. But figured I'd still post it in case others have a similar issue. tl;dr I had to set my number of TCP and UDP daemons in OpenVPN to 1. I do have 4 cores / 8 threads and this setting defaulted to 8. If you do cat /proc/cpuinfo from the console of the OpenVPN docker it shows 8 CPUs. I set it to 4 first with no luck then when I put it to 1 everything worked like a charm. -- I had similar problems as others with my docker container set to host mode. Reading through this thread (well, the last few pages anyway--it's a long thread), got me to the point that I could establish a VPN connection again. Unfortunately I could not access my LAN. I wiped the docker, the template, the appdata folder and all traces of the OpenVPN config from my DB, (I use mySQL as the backend storage for OpenVPN). Then I started from scratch also checking the Spaceinvader One video as well to make sure all my settings were the same (or similar--I have a different LAN subnet). I then set up a hotspot on my phone and connected my Android tablet to that. I could establish the VPN fine, but could not connect to anything after that. I could not hit the 172.17.x.x:983 address of the OpenVPN GUI or anything on my LAN. I then used tcpdump on a couple Linux VMs (one on the unRAID server also hosting the OpenVPN docker and another on a different unRAID server). I then tried to open SSH connections from my tablet to those using IP addresses. In both cases sometimes the SSH client would show a connection and sometimes even got a little through the cipher negotiation and things, but never finished the handshake. On the VMs I not only looked for SSH connections from the unRAID server IP, but IPs on the 172.17.0.0/16 subnet used by the docker and VPN clients. I could see packets from the unRAID server IP and nothing in the 172.17 range, so that was good. But the sessions, (if they even started--over several tests it probably finished the TCP/IP handshake half the time), never were fully established. On the VM side it ended with the VM sending the same packet back to the client waiting for an ACK. Unfortunately there are not sniffing tools as far as I know on the unRAID server or OpenVPN docker. On the server with the OpenVPN docker I also have mySQL and UniFi Controller dockers both in bridge mode. They do not give me any problems and at least the mySQL on is used fairly constantly, (also used by OpenVPN). Otherwise I would say it looks like something wrong with the NAT implementation.

Note that I am not clearing cookies or anything else when clearing the cache--just "Browsing history" and "Cached images and files".

Oh, what do you know, things show up on the web page now. So I added my desktop by clicking on it in the scan list (which remove it from there) and it showed up on the WoL tab. But then I navigated away and came back, and the desktop was gone from the WoL tab, (but was back on the scan list). I tried a few more times, did a reboot of the unRAID server and did another manual scan, but it would not seem to take. (FYI, I'm using Chrome on my desktop.) Then I put my desktop to sleep and used Dolphin browser on my phone. Now on the WoL tab my desktop showed up 6 times. So I deleted 5 of them, but when I navigated away then back to the WoL tab all 6 were back. Then I did remove all and they disappeared, but when I came back there were 6 again. So I did a FC on the browser and when I came back there were no entries on the WoL tab, but my PC did not show up on the scan tab! Now, back to the PC and it does show up on the scan tab, so I click on it and it moves over the the WoL tab, but disappeared again when I navigated back to the plugin page. SO, I then opened the Samsung browser on my phone and the WoL tab has one entry for my PC on it like it should. But Chrome (PC) and Dolphin (phone) do not show it! Next I cleared my cache in Chrome on the PC and...my PC is on the WoL tab like it should be. Next I turned on a different PC and on my desktop did a scan. It did not show up, but I cleared my cache and it's there. But it doesn't show up on my phone browsers (Samsung, Dolphin and Chrome). Then I cleared the cache on Chrome on my phone and it's there. Adding to the the WoL tab did not appear to take, but after clearing caches it's there as it should be. So, there seems to be some caching issue that at least affects Chrome on Windows/Android plus Dolphin and Samsung browsers on Android.

The nmap scan seemed to work fine on the command-line. Attached are the requested files. scan.xml network.cfg

Hm, this is not working for me again. I changed the NIC settings on one of my desktops now that Intel ANS is working again under W10 allowing me to set up 802.3ad link aggregation for it. So I went to WoL and first tried to delete the old MAC association, but it would not take, (it would disappear but when I reloaded the plugin settings screen it was still there). Then I did a scan and nothing showed up. I removed the plugin and reinstalled. This time the old association was gone, but a scan still came up empty. I tried on a second unRAID server I now have for testing, (clean 6.3.5 install), and the same thing with nothing found in the scan. (The second server is less complex with only a single network interface and no aggregation.)