Yet another Can't Access GUI post

[twistedlabel]

So, like many others I am no longer able to access my Unraid GUI after booting back up from a clean shutdown. I still have access to all of the docker images that I can remember the port numbers of. The only one that doesn't seem to be working is my Home Assistant, which was the most recently installed docker. I have tried every fix for this that i can find to no avail. I wouldn't call my self an Unraid NOOB but I am also far from an expert so theres a reasonable chance I didn't implement one of the fixes correctly.

 

Some of the fixes I've tried:

 

Shutting down docker and restarting nginx

changing the Unraid port number to several different unused ones

booting in safe mode

removing nvida plugin (this was a fix for me one of the other times i couldn't access the GUI, but that was after swapping almost all of my hardware out. I have restarted with no issue several times with my new hardware)

 

Two oddities I've noticed:

 

The recently installed Home Assistant docker doesn't seem to be working (I cant remember restarting my server after setting up the Home Assistant docker)

my router doesn't show a DNS lease to my unraid server but it shows up on a scan of my network with the self assigned ip address (not sure if this even matters as I don't know if it has ever shown up in my router, its just an odd thing I noticed. Im definitely a network noob

 

 

I did manage to get a diagnostic file which I've attached.

 

Thank you for any help you can provide.

timp-diagnostics-20230129-1242.zip

[trurl]

54 minutes ago, twistedlabel said:

changing the Unraid port number to several different unused ones

Why? That just seems like a good way to muddy the waters.

[trurl]

I recommend not setting static IPs on each specific device you want to have a known IP address. The best way to manage this is in the router. Let all devices use DHCP, and reserve an IP by MAC address in the router for devices you want to have known IP address. That way it is all managed in the one place that really matters.

[trurl]

How are you trying to access the webUI?

[trurl]

Can you ping the server?

[trurl]

Do you have an attached monitor and keyboard?

[twistedlabel]

41 minutes ago, trurl said:

Why? That just seems like a good way to muddy the waters.

This was a solution to several other users who had lost access to their GUI as a result of a conflict with docker port numbers. Their description of the issue sounded most similar to my situation compared to the other fixes i came across. And since all of my dockers are running except Home Assistant I thought it was worth a try incase I mucked something up in that setup.

 

32 minutes ago, trurl said:

Do you have an attached monitor and keyboard?

I dont have an attached monitor and keyboard, but I can make that happen.

 

34 minutes ago, trurl said:

Can you ping the server?

Yes. I can ssh into it also. Thats how I was able to generate a diagnostic report as well as tell my server to boot into safe mode

 

41 minutes ago, trurl said:

How are you trying to access the webUI?

though safari using my server.local name, using the ip address, and using the link to my server though the My Server section of this forum. All of which is how I normally accessed the GUI

 

44 minutes ago, trurl said:

I recommend not setting static IPs on each specific device you want to have a known IP address. The best way to manage this is in the router. Let all devices use DHCP, and reserve an IP by MAC address in the router for devices you want to have known IP address. That way it is all managed in the one place that really matters.

In trying to up my networking knowledge I have very recently been made aware that this is the best practice. And, of course, since everything has been running smoothly I hadn't made time to implement this change in my system. Ive only been following unraid tutorials up to this point so ive got a lot more to learn.

 

[trurl]

2 hours ago, twistedlabel said:

This was a solution to several other users who had lost access to their GUI as a result of a conflict with docker port numbers.

Set it back to 80 and 443. The whole point of docker port mapping is to avoid these conflicts. The container can use any port it wants and you map it to a different host port.

 

2 hours ago, twistedlabel said:

though safari using my server.local name, using the ip address, and using the link to my server though the My Server section of this forum. All of which is how I normally accessed the GUI

On what port though? If you changed the default webUI port you would have to specify the port in the URL.

 

You can delete or rename config/network.cfg on the flash drive to make it use default DHCP instead of trying to force it to use an IP that might already be taken by something else on your network. Maybe you are even forcing it to use an IP that isn't on the same LAN.

 

You have some other serious problems I'm just noticing, more about that in next post

[trurl]

Seeing some of these

Jan 26 03:40:02 Timp kernel: BTRFS warning (device sdd1): csum failed root 5 ino 19057338 off 499060736 csum 0xbd14c011 expected csum 0xb18f73ea mirror 1
Jan 26 03:40:02 Timp kernel: BTRFS error (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0, corrupt 758, gen 0
Jan 26 03:40:02 Timp kernel: BTRFS warning (device sdd1): csum failed root 5 ino 19057338 off 499060736 csum 0xbd14c011 expected csum 0xb18f73ea mirror 1
Jan 26 03:40:02 Timp kernel: BTRFS error (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0, corrupt 759, gen 0
Jan 26 03:40:02 Timp kernel: BTRFS warning (device sdd1): csum failed root 5 ino 19057338 off 499060736 csum 0xbd14c011 expected csum 0xb18f73ea mirror 1
Jan 26 03:40:02 Timp kernel: BTRFS error (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0, corrupt 760, gen 0
Jan 26 03:40:02 Timp kernel: BTRFS warning (device sdd1): csum failed root 5 ino 19057338 off 499060736 csum 0xbd14c011 expected csum 0xb18f73ea mirror 1
Jan 26 03:40:02 Timp kernel: BTRFS error (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0, corrupt 761, gen 0

which suggests bad RAM.

 

[trurl]

Jan 25 20:12:59 Timp nginx: 2023/01/25 20:12:59 [crit] 5177#5177: *3145 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 154.89.5.75, server: 0.0.0.0:6969
Jan 26 11:32:41 Timp nginx: 2023/01/26 11:32:41 [crit] 5177#5177: *76252 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 87.236.176.233, server: 0.0.0.0:6969
Jan 27 01:13:35 Timp nginx: 2023/01/27 01:13:35 [crit] 5177#5177: *141479 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 23.225.180.198, server: 0.0.0.0:6969
Jan 27 21:15:51 Timp nginx: 2023/01/27 21:15:51 [crit] 5177#5177: *236473 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 185.165.190.34, server: 0.0.0.0:6969
Jan 28 14:15:24 Timp nginx: 2023/01/28 14:15:24 [crit] 5177#5177: *317157 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 94.102.61.54, server: 0.0.0.0:6969
Jan 28 19:02:50 Timp nginx: 2023/01/28 19:02:50 [crit] 5177#5177: *340459 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 154.89.5.107, server: 0.0.0.0:6969
Jan 29 02:01:45 Timp nginx: 2023/01/29 02:01:45 [crit] 5177#5177: *374060 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 87.236.176.55, server: 0.0.0.0:6969
Jan 29 09:59:54 Timp nginx: 2023/01/29 09:59:54 [crit] 5177#5177: *413159 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 212.102.40.218, server: 0.0.0.0:6969

https://www.abuseipdb.com/check/154.89.5.75   Hong Kong

https://www.abuseipdb.com/check/87.236.176.233   UK

https://www.abuseipdb.com/check/23.225.180.198   USA

https://www.abuseipdb.com/check/185.165.190.34   USA

https://www.abuseipdb.com/check/94.102.61.54   Netherlands

https://www.abuseipdb.com/check/154.89.5.107   Hong Kong

https://www.abuseipdb.com/check/87.236.176.55   UK

https://www.abuseipdb.com/check/212.102.40.218   USA

 

[trurl]

Did you know your SSL port was set to 6969? Those bots listed above figured it out.

@twistedlabel

Take your server off the internet NOW!!!

[twistedlabel]

 

7 minutes ago, trurl said:

Did you know your webUI port was set to 6969? Those bots listed above figured it out.

@twistedlabel

Take your server off the internet NOW!!!

I did not. Look into that. And its offline now. Thank you. Aside from needing to change that port is there anything else i can do/should worry about those bots?

 

25 minutes ago, trurl said:

Set it back to 80 and 443. The whole point of docker port mapping is to avoid these conflicts. The container can use any port it wants and you map it to a different host port.

 

On what port though? If you changed the default webUI port you would have to specify the port in the URL.

 

You can delete or rename config/network.cfg on the flash drive to make it use default DHCP instead of trying to force it to use an IP that might already be taken by something else on your network. Maybe you are even forcing it to use an IP that isn't on the same LAN.

 

You have some other serious problems I'm just noticing, more about that in next post

 

Ill get the ports resent and get it bak to the default DHCP. The IP address it has is on my system but ill redo things the correct way moving forward.

 

Ill also get some diagnostics going on my RAM. 

 

Thanks again!

[trurl]

1 minute ago, twistedlabel said:

I did not. Look into that. And its offline now. Thank you. Aside from needing to change that port is there anything else i can do/should worry about those bots?

You shouldn't put your server on the internet. Only forward specific ports to your server for specific purposes, and access to your webUI or command line should definitely not be exposed. Changing the port isn't going to help, they will just find it again. Don't put those ports out there.

 

This is something that you must have setup in your router, they aren't setup that way normally. Were you trying to make it easy for you to access your server remotely? You made it easy for everyone else too.

 

https://wiki.unraid.net/Manual/Security

 

 

[trurl]

Wireguard VPN is builtin to Unraid and is an easy way to allow secure remote access.

[twistedlabel]

@trurl Thank you so much for pointing me in the right direction.

 

I dont know in what fever dream state i decided to add those port forwarding options in my router but they have been nuked. I dont need remote access to my server other than through the My Server plugin and that is now set up properly.

 

I reset my DHCP by deleting config/network.cfg on my flash drive

I then reset my port numbers by editing the config/ident.cfg file on my flash drive. 

 

Reading though the list of security best practices, I thankfully have done/follow most of them (with the obvious exception of my huge port forwarding mistake)

 

I now have access to my web GUI and have a lot more knowledge in my tool belt. Thanks again!!!

[trurl]

You should do memtest because of those btrfs csum errors I mentioned.

[twistedlabel]

18 minutes ago, trurl said:

You should do memtest because of those btrfs csum errors I mentioned.

Its on the to-do list! Thanks!

[trurl]

1 hour ago, twistedlabel said:

Its on the to-do list

Should be on the doing it now list.

 

You don't want to even try to run a computer unless the memory is working perfectly. Everything goes through RAM, the OS and other executable code, your data, everything. The CPU can't do anything with anything until it is loaded into RAM.