Outlaws

Very cool, that was the problem. I re-added the default route as 'Route 0.0.0.0/0, <gateway IP>, metric 0'. Connect is back online and the dockers have wider network access again.

Hi Jorge, I think that I may have found the issue. I noticed that no Docker containers in bridge mode were reachable, only those with an assigned IP in my lan subnet (Plex, PiHole). When I check the network settings, it looks like I'm missing the default route to the gateway somehow? I think that certainly explains the behavior being seen. This 'working' node is still on 7.0.3, so the page looks just a bit different. I was not able to find a page for this setting in the Docs. Can you confirm that I should enter route:"default", address:"192.168.1.1 via eth0", and metric:"0" in those fields? I can then see if things come back, or let me know if there is another way to correct that. This node: Working unit:

Hey Jorge!! I hope you have been well, thank you for taking the time to review this concern. Unfortunately the network on the box does seem functional outside of Connect/the apps tab for a few reasons, if it were experiencing a complete network outage that would be much easier for me to continue troubleshooting. I did find that the GluetenVPN docker does not function, and doesn't seem to get network access (pings fail as well), but that is the only other hiccup I've seen aside from Connect. Working on the machine, I can: Access webGUI/SSH/perform file transfers from another LAN host I can access the Plex docker from LAN and WAN The Pihole docker is online, reachable, taking DNS traffic. This docker is NOT configured as the host machines DNS, I know that is not permitted. Yesterday, I was able to access the webGUI and manage the server via https://connect.myunraid.net -> Server Details -> Manage, however this now appears to now be getting stuck on 'Loading'. That is definitely the behavior I would expect, and I found it odd that I was able to access the device remotely yesterday from connect.myunraid.net, where it would still the Connect 'connection error' alert. Apologies that I did not get a screenshot of this behavior. I believe that previous screenshot shows the unraid-api as "status: online" and able to install a plugin over the network, but I may not be interpreting this output correctly. For the ping commands, I believe that output is indicating that ping fails because Connect itself it reporting it does not see a network? I may be misinterpreting that as well, but I can query the box from other network nodes and see ping responses without issue.

Hey all, I performed a hardware upgrade on one of my servers this morning, and all is well except for that it is now showing an Unraid connect error: NETWORK: queryA ECONNREFUSED mothership.unraid.net CLOUD: Socket closed This is a 7.2.2 box using the onboard motherboard NIC, which is the same thing I had before (different motherboard but no secondary NIC/wifi). I took the flash backup from Connect before the hardware change, but since I have started the machine, it has not been able to reconnect to the Connect plugin. Network access itself appears fine, as I can reach the docker containers and webGUI. I changed the DNS settings to the recommended 208.67.222.222 / 208.67.2220.220 and rebooted the machine, but still no change. I saw it recommended in another thread to try this plugin install command via the CLI, this appears to have taken but I still see the same error. I've attached Diagnostics, so please let me know if there are any recommendations for next steps. Thanks, Outlaws unii-diagnostics-20260110-1221.zip

Perfect, I figured that was the next step and just wanted to confirm. Worked great!

Hey, sorry if this is a silly question - how can I update my v6 container like referenced in the post above? I converted from the old v5 a couple months ago and haven't kept up since - it's currently set on devzwf/pihole-dot-doh:latest-v6, but I haven't seen any updates in a long while and wanted to check if that had been deprecated.

Great, thanks for the confirmation! With that, I should be all set. I will keep an eye on the machine and hopefully the parity check completes without issue.

Yessir, I am 99% good and the only thing remaining is to regain some confidence in the new hardware, or finish backing it out. But I'm going to let the server sit for a few days and monitor things to make sure it's behaving as normal. I have the server configured to begin a parity check on 3/1, and am hoping I can use that to see if there are any issues with the new memory. If there are parity errors detected, I would then try to revert to the old cpu/ram/mobo and check parity again to see if those errors are valid. Because I don't know for sure that the memory integrity is 100% stable, I do NOT want 'write corrections to parity' enabled for the first run. I have disabled this under Settings -> Scheduler, but the setting remains enabled under the 'Main' tab. I can uncheck it, but it becomes checked again if I refresh the page. 1. Is the setting on the 'Main' page only for parity checks that are manually started after disabling it, which is why it appears to reset? 2. I assume then that the setting under 'Scheduler' is the only one that will be used for the scheduled parity run?

I am having a very good laugh now. Trurl, I think you might too - this actually fixed it & see your post at the bottom. I'm back in plex and ready to rock on.

Apologies, here is a new Diag as well. unii-diagnostics-20250226-0642.zip

Hi All, Thank you for the help!!! I have mostly good news to report. I was able to set the shares back to Primary:Cache, stop the array, remove the new pool, and restart the array without issue. Once I started Docker again, the original containers re-appeared. Most of the containers seem to be good - however, the most important container in binhex-plexpass seems to have become broken? I've attached the output of the GUI and container log to this post, but recognize it may be best to start a new thread or post in the Binhex thread for further support with this specific issue. I don't see any specific error in the container log except a usb error, and I can verify the container has network connectivity from it's console. binhex-plexpass container log.txt

Sorry for the bump - a few quick edits to the plan above before I move forwards tomorrow morning. I think the best action would be to have the shares configured correctly before stopping and restarting the array - so they know exactly where to look for their original files. I plan to disable docker, flip them back to primary:cache, but not invoke the mover. Fingers crossed & I will let you know how it all goes!

Understood. I will probably take more actions tomorrow after I can finish testing the old equipment that I want to reinstall. So the current plan from my side would be to: 1. Take diag/flash backup 2. Not change share settings/mover actions 3. Disable Docker service 4. Stop the array 5. Remove the new SSD from the new 'cachefast' pool 6. Remove the new 'cachefast' pool 7. Start the array and pray all the disks show healthy 8. Start the Docker service, and see if containers have restored 9. Take diag/flash backup 10. Pause if things appear to have returned to normal, and consider if I still want to proceed with hardware backout Does that sound right, or would you modify any steps?

Jorge, thank you for confirming that these logs are not indicating another issue on my side!! I am still most likely going to revert the hardware change so I can regain some trust in the system, and that will allow me to test that new hardware further outside the chassis. My main question at this point is what settings I should configure for the appdata/system shares prior to shutting down? I am most likely going to remove the new 'cachefast' SSD after all, and repurpose that for another system. For that scenario, would it be best to 1. configure the shares as 'cache' only, not pointed to 'cachefast', and then 2. restart and mount the array without the 'cachefast' pool? Should I avoid invoking the mover since the original containers/data should still exist on 'cache', and it may try to overwrite them with the new files on /cachefast/? I can see via the File System that it created a docker.img file in /cachefast/system which is the same size as the one in /cache/system I have attached a backup of the config/shares folder from before any of these changes if that would be helpful to compare vs the current settings. Thank you again for all the assistance so far! Thomas/Outlaws original shares.zip

Hi trurl, I think the only thing that will make me trust this machine again is to remove the new hardware (motherboard/processor/memory) - except the new SSD, since that can be disabled via software. I am going to revert back to a known good combination of hardware hopefully Wednesday, once a part arrives overnight and I can spend some time testing it outside of the unraid box. When I looked at the Log from GUI, I can see that it reports a kernel panic overnight at 1:15am. This looks similar to the kernel panic that caused the machine to hang & reboot the morning prior. If you have any interest, I've attached a current diag + log + a capture of the original kernel panic. One thing I am still wondering - why is Fix Common Problems alerting for this? Could it not be recognizing both pools as cache for some reason? appdata: Primary: Cachefast, Secondary: Cache Feb 23 12:58:34 Unii root: Fix Common Problems: Error: Default docker appdata location is not a cache-only share unii-diagnostics-20250224-1540.zip unii-log.txt