So, aside from occasional SMB access issues that would require a reboot, my tower has been running fine. Today, I had my shares become inaccessible, so I went to reboot it... Can't connect to the web GUI. Can't ping the tower. Connect a monitor and keyboard to the tower; was able to type in username "root", but when I hit enter, it goes to a new blank line; whatever I type shows up, but it isn't taking it as a password. 60 seconds later it times out and the CLI login resets, asking for username.

 

Since I can't connect to the web GUI and can't log into CLI... is there anything I can do? Or do I just need to do an unclean restart and hope the array isn't impacted?

 

Current version is unRAID 6.11.5

A short press of the power switch on the server is meant to initiate the standard Unraid shutdown sequence (as though you used the Shutdown button in the GUI).

Alright, so that did gracefully shut it down [I didn't realize it would stop the array, I thought that had to be done before sending for shutdown] -- unfortunately, after starting it up again, it seems to be in the same state. Can't ping it at the IP it lists, same behavior with not taking a password and timing out... Is my only option to try rebuilding the flash drive at this point, since I can't log in at all?

You can download and post the diagnostics to see if there's something visible.

7 minutes ago, JorgeB said:

You can download and post the diagnostics to see if there's something visible.

Are the diagnostics files stored anywhere on the flash drive that I can access from another machine? I'm not even able to log into the CLI at this point [I didn't see anything listed in the link about what to do if CLI is inaccessible]

You can remove the flash drive and connect to a PC, they will be in the /logs folder, it's all in the link if you click it.

On 6/14/2023 at 9:37 AM, JorgeB said:

You can remove the flash drive and connect to a PC, they will be in the /logs folder, it's all in the link if you click it.

Ahh, sorry, I thought /logs was the full logs without anonymization. Here you go!

 

---

Edit: removed diags because I realized they weren't sanitized.

 

Edited July 7, 20232 yr by unTECH

No link detected on bond0, which is your main interface, there's is link on bond1, swap cables or make the other NIC eth0, you can also just delete/rename /config/netwrok.cfg and network-rules.cfg and reboot, it will default to a bond with all NICs and DHCP.

Hmm... So, turns out the main cable had slightly wiggled out of the port on the switch somehow. Swapped that out, now I see activity on all 3 interfaces from the back of the machine. However, I still can't ping it, connect to the web GUI, or log into the CLI... Going to try renaming the network files you mentioned

16 minutes ago, unTECH said:

Going to try renaming the network files you mentioned

If this doesn't work post new diags.

Ok, so, interestingly... I tried just renaming network-rules.cfg, and it would recreate that file but still not work. Renaming both, it creates a new network-rules.cfg, but not network.cfg. It won't get a proper IP address [seems to default to 169.254.221.41, which is not in any of our scopes], but I can log into the CLI after renaming both. Which is good that it did, because it didn't automatically do diags with later reboots, so I was able to run the command.

 

 

---

Edit: removed diags because I realized they weren't sanitized.

Edited July 7, 20232 yr by unTECH

6 minutes ago, unTECH said:

but not network.cfg

That's normal, it would be created when you make a change.

 

Jun 14 06:54:33 Discovery  dhcpcd[1406]: br0: soliciting a DHCP lease
Jun 14 06:54:38 Discovery  dhcpcd[1406]: br0: probing for an IPv4LL address
Jun 14 06:54:44 Discovery  dhcpcd[1406]: br0: using IPv4LL address 169.254.221.41

This is usually a router problem, it's not leasing an IP address.

 

 

2 minutes ago, JorgeB said:

That's normal, it would be created when you make a change.

 

Jun 14 06:54:33 Discovery  dhcpcd[1406]: br0: soliciting a DHCP lease
Jun 14 06:54:38 Discovery  dhcpcd[1406]: br0: probing for an IPv4LL address
Jun 14 06:54:44 Discovery  dhcpcd[1406]: br0: using IPv4LL address 169.254.221.41

This is usually a router problem, it's not leasing an IP address.

 

 

Hmm... There's a DHCP reservation for the server, must be hitting something there. I'll investigate the network side and follow up.

So, update: Had some network issues take out a Windows server, so several changes were made; I was able to get the server accessible via the webGUI again.

Now, this is great, but there's still the CLI login issue. Put in the username, it goes to a new line, but isn't actually taking the password; whatever I type shows in plain text. After 60 seconds it times out.

I did find that if I boot the server in GUI mode, I can log in and do what I need to do, so it's not a huge problem... But still seems like a bug. I've now updated to 6.12.1 and it still does it.

3 minutes ago, unTECH said:

Now, this is great, but there's still the CLI login issue. Put in the username, it goes to a new line, but isn't actually taking the password; whatever I type shows in plain text. After 60 seconds it times out.

Not sure what it could be, but it works for me, it's not a general bug.

 

Just now, JorgeB said:

Not sure what it could be, but it works for me, it's not a general bug.

It's definitely weird. I did notice that when I removed the network config files it would work, but then once I set the network up again, it would stop working... I guess I'll just ignore it since it isn't really causing an issue. Thanks for the help