I recently started seeing “Invalid Certificate 1” errors in my Fix Common Problems output on array stop/start. I usually only stop to add or update drives, with hasn’t been all that often so I’m not certain when this began.

 

I found several posts about how to address this in Management Access, and was able to add my *****.unraid.net address to Pihole/Unbound and address the certificate error.

 

Today we lost power long enough for the UPS to shut down the whole system, and once it came back up I can no longer access the Unraid UI. The system is up, Docker containers are running, VMs are running, nothing else is using port 81, I can access drives, connect via SSH…everything you would expect the system to do, save for getting access to the UI.

 

I’m at a loss about where to troubleshoot. With only having made that one change to the system recently, is addressing the SSL error a red herring and I should look elsewhere, or is there more to registering my *****.unraid.net address?

 

Let me know what other diagnostic information would be helpful and I’ll update it here.

1 hour ago, spalmisano said:

Let me know what other diagnostic information would be helpful

attach diagnostics to your NEXT post in this thread

Diagnostics taken via CLI at 21:04 EST.

Thanks again.

media-diagnostics-20220120-2103.zip

1 hour ago, spalmisano said:

nothing else is using port 81

Why are you not using the default port 80?

Tech debt from setting up Unraid years ago. Port 80 is being used by a Docker container and I’ve been using 81 ever since.

 

Is there something in the diagnostics showing 81 now not having a correct configuration? It’s worked perfectly since. 

You can't access the WebUI via local IP address?

Correct. All browsers report connection failed. 

9 hours ago, MrGrey said:

You can't access the WebUI via local IP address?

What IP address are you trying? Are your other computers on the same subnet as your Unraid server?

 

Can you access the webUI directly on the server in GUI mode with an attached monitor and keyboard?

 

 

3 minutes ago, trurl said:

What IP address are you trying? Are your other computers on the same subnet as your Unraid server?

 

Can you access the webUI directly on the server in GUI mode with an attached monitor and keyboard?

 

 

 

The IP of the Unraid machine is 10.10.0.2. Since I’ve got it configured at port 81, the UI has always been at 10.10.0.2:81/Main

 

There’s only the one subnet for the main network, and yes all the other machines are on that subnet. There’s a guest network that’s isolated and rightfully cannot access the Unraid UI.

 

The server itself does have a KVM attached but I’ve only ever seen a command prompt after booting. I’ve only been able to access the UI remotely.  I admit to not having paid attention to the boot options recently. Is there an option to have the UI enabled on the server?

 

6 minutes ago, spalmisano said:

 I admit to not having paid attention to the boot options recently. Is there an option to have the UI enabled on the server?

yes

Ok thanks. I’ll do a reboot in a bit and report back. Appreciate the help.

Successfully rebooted into GUI mode. Everything comes up (services, containers, VMs, et cetera) as before. I can log into the server directly but still cannot access the web UI. Firefox reads it cannot establish a connection. Normal browsing, both internal and external works as expected, including other sites on the 10.10.0.* subnet.

 

What other information can I give or try on the server?

You have some extra stuff in your go file. Revert to stock go and see if that makes a difference.

Go is now: 

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp
# cp /boot/config/.bash_profile /root/

# install sg3 utility to control SA120 fan speed
# installpkg /boot/packages/sg3_utils-1.42-x86_64-1.txz

 

With no change in behavior after a reboot.

 

Aside from addressing the certificate error recently, the only other maintenance/changes have been

• ‘Fixed’ the DNS rebinding issue with adding *****.unraid.net entries in PiHole and Unbound. Those entries only have 10.10.0.2 and not the port number (81) since you can’t specify a port in PiHole for custom DNS.
  • Removing those entries doesn’t fix this UI access issue.
• Added a disk shelf with six more drives: one 10TB and five 4TBs.
  • Two of the 4TBs showed up in the array but were never assigned to the array. I assumed Unraid saw a fault with them and wouldn’t allow them to be added. I’ve since removed both from the array and they show up in unassigned devices.

 

I know troubleshooting remotely is a pain, but I appreciate your willingness. If there’s anything detail-wise I can provide, let me know.

1 hour ago, spalmisano said:

Go is now: 

Yes I could see that, it is not stock. No obvious reason that wouldn't work but I thought maybe the modified go wasn't completing for some reason so I suggested replacing it with stock go file.

I notice in syslog you had two new array disks 20 and 25. If they weren't precleared, Unraid would clear them so parity remains valid. But then I see I/O errors on both of the new disks. Looks like controller problems.

With the extra syntax commented out isn’t it now the same as stock? 

1 minute ago, trurl said:

I notice in syslog you had two new array disks 20 and 25. If they weren't precleared, Unraid would clear them so parity remains valid. But then I see I/O errors on both of the new disks. Looks like controller problems.

Yes see previous post. I removed those two from the array and they’re now in unassigned devices. I’ll remove them from the shelf as well. 

4 minutes ago, spalmisano said:

With the extra syntax commented out isn’t it now the same as stock? 

yes, didn't notice you had commented out

nginx (the web server) can't start because it is trying to use port 444 for SSL and that is already in use.

 

from config/ident.cfg:

USE_SSL="auto"
PORT="81"
PORTSSL="444"

 

from syslog:

Jan 20 08:45:22 media nginx: 2022/01/20 08:45:19 [emerg] 21141#21141: bind() to 0.0.0.0:444 failed (98: Address already in use)
Jan 20 08:45:22 media root: nginx: [emerg] bind() to 0.0.0.0:444 failed (98: Address already in use)

 

There is probably a conflict with a docker container. 

 

If you want to use the docker on port 444, edit config/ident.cfg and change the PORTSSL to something that is not in use and reboot. Then the unraid webgui will use that new port.

 

If you want to use the webgui on 444 then edit config/docker.cfg and change DOCKER_ENABLED="yes" to "no", then reboot. When it comes up you can then start docker and change the port of whatever docker container is trying to use 444.

That makes sense given I just enabled SSL for the web UI. Thanks for the detective work.

 

A few of my Plex users have started up for the night, but I’ll change this and then reboot when I can. Once I’ve confirmed this is fixed I’ll post notes and mark as solved.

22 hours ago, ljm42 said:

nginx (the web server) can't start because it is trying to use port 444 for SSL and that is already in use.

 

from config/ident.cfg:

USE_SSL="auto"
PORT="81"
PORTSSL="444"

 

from syslog:

Jan 20 08:45:22 media nginx: 2022/01/20 08:45:19 [emerg] 21141#21141: bind() to 0.0.0.0:444 failed (98: Address already in use)
Jan 20 08:45:22 media root: nginx: [emerg] bind() to 0.0.0.0:444 failed (98: Address already in use)

 

There is probably a conflict with a docker container. 

 

If you want to use the docker on port 444, edit config/ident.cfg and change the PORTSSL to something that is not in use and reboot. Then the unraid webgui will use that new port.

 

If you want to use the webgui on 444 then edit config/docker.cfg and change DOCKER_ENABLED="yes" to "no", then reboot. When it comes up you can then start docker and change the port of whatever docker container is trying to use 444.

 

This was obviously the issue. Simply choosing another port in ident.cfg for SSL allowed the web UI to start. Editing that file and rebooting had things back to normal.

 

A simple review of syslog on my part as a first step likely would have pushed me into the right direction. Won’t forget that next time.

 

Thanks again for all of the help.

Glad you're back up and running!

Thanks for sharing