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?

Well, I don't know what happened but it's reverted back and also got worse. We had the power flicker a few days ago because of a storm and ever since then the server has just been fighting me. I can't ping any internet site, URL or IP. Something went wrong with the SSL cert/HTTPS access so I had to turn that off and delete the cert to access the server. When I check for updates on Plugins or Dockers I get Not Available/Connection failed responses. It was super stable up until Monday. Hopefully the attached diagnostics show something. I wish I knew what I was looking for but I feel like since nothing changed, I have no idea where to start looking. I appreciate the help from anyone willing! tower-diagnostics-20220806-2359.zip

So far, this has fixed the problem! I'll keep an eye on it for a bit more and update again. I really appreciate the suggestion/help @Vr2Io!

Not sure how I missed that when I tried it the first time! Thanks for the help on that. Hopefully I can get this wrapped up soon to see if it helps.

I cannot figure out how to get the Pihole docker on eth1. I connected it to my router and set it up in Unraid. I tried it with and without bridging, with and without a default gateway, and with and without a VLAN (which matches a VLAN I created in the Unifi controller). I see stuff in the Routing Table pertaining to the eth1 interface. Do I need to also create a custom docker network titled br1 that is an ipvlan type with the 192.168.2.1 info in it? Or should I create a new VLAN on eth0 for it instead of a separate network interface? I'm not sure what the difference would be.

I removed VLAN30 from Unraid and tried setting the server in the Unifi Controller to have a 192.168.30.x IP but it will not take. I can VNC into the VM and see the desktop but it is unusable. Is there something else I have to do to get it a correct IP or is adding the VLAN back in to Unraid the only way? The network source options I have in the VM are just virbr0 and br0. Here's what I changed in Unifi for the client machine. The settings will not save the Surveillance network and reverts back to the Default one, but the IP stays.

I have it defined in the network level as well so maybe it's not necessary. I'll have to test with it and see what happens.

VLAN 30 is for my security cameras/software. I have Blue Iris running in a VM (via Unraid) with a 192.168.30.x IP. Maybe the VLAN definition isn't necessary in Unraid then? Pihole is on a custom br0 network. This is the same IP range as my default untaged VLAN that houses all of my main devices. I have separate VLANs for IOT items and security cameras. I'll have to see if I have another open port on my switch. I didn't think I'd use an eight port switch up quickly but it's full or all but. If I do, I'll try the suggestion above by putting Pihole on it's own VLAN. This is how I currently have my untaged VLAN set to resolve for the Pihole in the Networks section of Unifi Control.

I tried restarting my Unifi USG on its own (and not stop/start the array) and that also fixed the issue. Anyone have an idea why just this server is getting hung up on the router?

It has since reverted back to having a DNS issue. Does anyone have any suggestions on what to look at?

I've been running into this issue for some time now and cannot figure out what might be causing it. Hopefully my information below and the two attached diagnostics files can aid someone in helping me troubleshoot. When I first spin the array up, I'm able to ping URLs/IPs, I am able to update docker containers/plugins, DuckDNS works to access Emby, and I don't get any errors in Fix Common Problems. After a while, all of the above breaks. I tried researching and found a lot of threads with similiar issues but nothing that contained a resolution that has worked for me. One thing you may see in the diagnostics files is that one of my DNS Servers is my router. This was a recent change I made per this thread. It did not help. I have Ubiquiti gear for networking (USG is my router). My server is on the same network (192.168.1.x) as the rest of my personal devices in the house. I do have that network set up in Unifi Controller docker with a with a manual DNS of my Pihole docker so that all traffic routes through it. But the Unraid server is set for Quad9 and Google's public DNS servers (and the router, per the above comments for testing purposes). I do not see any traffic in Pihole from the Unraid server's IP. Any suggestions on how to further troubleshoot this issue? I don't have any issues on other devices and the fact that it resolves itself after I spin down the array and stays resolved after I spin it back up for awhile points to something on the Unraid server to me. I just don't know what would cause an issue like this. Diagnostics files -0913.zip was from when the issue was happening -0929.zip was from after I restarted the array and the issue was resolved tower-diagnostics-20220627-0929.zip tower-diagnostics-20220627-0913.zip