snowborder714

Party check is complete and it had a bit over 1000 errors. I then ran a non-correcting check now and it came back with zero errors. Thanks again!

I assume by that you mean run a parity check with the "Write corrections to parity" option checked?

That seemed to have worked! I had found a lot of things saying to check the "parity is already valid" but didn't know about the New Config option. For reference, I checked all of the pervasive options to keep the current disk assignments. I couldn't really find too much about whether that was necessary or not.

My USB flash drive died yesterday so I went through the process last night to create a new one. I have CA Backup / Restore Appdata installed and it was taking flash drive backups to my system. I thought I had Unraid Connect set up (I know it was installed) but was unable to get anything to load. I was able to pull the drive from Unraid that had the backups on it, mount it to my Windows laptop using PowerISO (it's in XFS format), pull the config folder from the backup, and paste it to a freshly formatted USB drive using the Unraid tool and the latest stable version. With this, I was able to get the server back up and running but I had no array disks mapped. After some more searching, I found that the plugin stores the file with the name of super.dat.CA_BACKUP so as to not cause issues if it was named super.dat. After removing the ".CA_BACKUP", I rebooted and most of my drives are now there and the array started without issue. I have two drives I've added to the system since that backup was taken (I'm guessing) and I see them the Unassigned Devices tab. I also have a drive that lives in Unassigned and am able to distinguish which one that is compared to the other two that were in the array. When I try to add the two drives to the array, I'm presented with a note that all the data will be erased when the array is started. How am I able to add these back into the array without having them wiped?

I ended up removing swag and all associating files and just setting it all up again. It's back to having a working SSL cert and everything resolving via HTTPS.

I'm not sure when it happened (somewhat recently though) or what happened but all of my reverse proxy apps that I've setup with swag and duckdns are throwing an SSL cert error of NET::ERR_CERT_AUTHORITY_INVALID (see attached image). I had this setup and working on Emby and Nextcloud for a long time but recently saw that accessing those resulted in it just using HTTP. I've attached a diagnostics file for review. The logs for swag look clean and the certs look to be in good standing and not expired. I'm at a loss at the moment as to where to look next so any help would be greatly appreciated. tower-diagnostics-20221028-1643.zip

I previous removed my comment about my access issue as I had thought it was my wireless system on the fritz. My USG was acting up and I had to rebuild my wifi config to get it to work again. All is well now. Hopefully it stays this way for a while!

I believe I can't delete that one because it is a "default" item because of having two ethernet cables into the server. I figured out how to assign a new metric and I'm able to ping various external IPs and domain names now. Going to test a few more things and see if it stays working.

I did try to delete the eth1 routing table entry but for some reason it didn't actually delete. Looking to see if I can find the command to use via the terminal instead.

Here's the details on the first line in the screenshot. They all looks like this so the gateway is correct.

Well, here's something odd. I can access Unraid via two different IPs ater chaning it to dynamic control. Now I'm really confused!! I don't know how these two networks in Unraid work but maybe this is something related to what you mentioned above. Here's what it shows in the Unifi controller.

Correct, it has two ethernet cables going to the switch. One for the main network (192.168.1.x) and one for the Pihole network that you suggested above (192.168.10.x). I changed it to off a static IP to see if that was causing any issues but it doesn't look like anything changed. Below are pings to 192.168.1.1 (USG), 9.9.9.9, 8.8.8.8, and 192.168.1.7 (Synology NAS, plugged into another port on switch).

I have a Unifi network in place. Unifi Controller - running via docker in Unraid USG - Unifi Security Gateway 8 port switch Couple APs Let me know what info you'd like to know and I'll do my best to provide it.

My personal devices (laptops, desktops, phones) and both of my servers (Unraid and Synology NAS) area all in the first item in the below screenshot (192.168.1.0/24 subnet). Yup, I had read for Unraid not to use Pihole so that's why I set it up that way. Just didn't know if the network setting for everything to route through Pihole DNS and then telling Unraid to not use it would cause any issues. I didn't think so but wanted to make sure.

Thanks for taking a look. I tend to agree but am just baffled at how all other devices with a 192.168.1.x IP can access the internet just fine but the server can't. Is there a possibility that with the Pihole DNS assigned at the network level for all 192.168.1.x IPs but Unraid set differently at the server level might cause an issue? Or should I just create a new network (e.g. 192.168.10.x) and move either the Unraid server or all other home devices to that to separate them out? Or shouldn't it really matter?