Hi all,

 

Our Unraid server has experienced a power outage. After rebooting the machine it appears that the device's name has been reverted to the default "Tower", and I cannot log into the root account with the previous user/password combination. Unfortunately I do not have physical access to the server for the foreseeable future, which is why I cannot follow the steps laid out in the password recovery section.

 

What I don't understand is the following: I can connect without problems to the WireGuard server that runs on the machine. Some docker containers also seem to have been restarted as the Twingate connector docker container is also online (I could verify it from Twingate's website).

 

Things that work:

- I have access to the file shares (non-root user)

- WireGuard server

- Twingate docker container running on the OS

 

Things that don't work:

- Unraid is running on the wrong port (previously remapped to 8080 due to using NPM, now running on 80 again)

- SSH seems to be disabled on an OS level

- Root account password seems to have been reset

 

Questions as follows:

- Is there any way to reset the password remotely in this scenario without having physical access to the computer?

- How does a server end up in such a weird mix of half working / half not working state?

 

Thank you!

Edited August 13, 20241 yr by daemuth

Without physical access I can't think of a way to reset the password. If there was, it would probably be exploitable by nefarious actors.

 

However, the answer to the question how it happened, is that a file or file(s) on the boot USB got corrupted by the hard shutdown. It would be worth a try to use root with no password at the GUI and see what happens. Hopefully it will accept a blank password and immediately ask you to set one, as if it was a new server.

9 hours ago, JonathanM said:

Without physical access I can't think of a way to reset the password. If there was, it would probably be exploitable by nefarious actors.

 

However, the answer to the question how it happened, is that a file or file(s) on the boot USB got corrupted by the hard shutdown. It would be worth a try to use root with no password at the GUI and see what happens. Hopefully it will accept a blank password and immediately ask you to set one, as if it was a new server.

I see, that's a valid point.

In that scenario, assuming I get access to the faulty USB drive, what steps do I need to take to restore it in working order? Everything else apart from the OS config seems to be in working order. I have a backup from the beginning of the year and I haven't modified much in OS since then. It would be nice if I wouldn't have to delete WG / docker configs etc

When you get on site, try to stop the array, and then power down safely from the GUI.

 

Put the USB in another machine, copy the entire config folder and do a checkdisk on the USB. Corrections or not, make another copy of the config folder just to be safe.  Examine the ident.cfg file in the config folder, it should be plain text and obvious if there is something wrong. Possibly it was corrupted and regenerated with defaults, which would explain the reversion to "TOWER". You can browse around the files in the config folder looking for corruption, the vast majority of the files are plain text, notable exceptions would be the .key file and super.dat.

 

Follow the online directions for resetting the password, and you should be good to boot back up, if you have a flash backup you can use the config folder from the backup as reference files to fix any corruptions found.

 

I've personally dealt with something very similar on one of my machines a few years ago, when it happened to me the only corrupted file was the ident.cfg, but you probably should poke around and check other files just to be safe.

 

If you know how to do a binary compare, you can check the current copy against the config folder from your backup, and examine the differences found. I wouldn't mess with differences in non-text files, but all the plain text stuff is pretty easy to parse and see if it makes logical sense.

 

I think you will probably be fine based on your description of events.

On 8/14/2024 at 1:22 PM, JonathanM said:

When you get on site, try to stop the array, and then power down safely from the GUI.

 

Put the USB in another machine, copy the entire config folder and do a checkdisk on the USB. Corrections or not, make another copy of the config folder just to be safe.  Examine the ident.cfg file in the config folder, it should be plain text and obvious if there is something wrong. Possibly it was corrupted and regenerated with defaults, which would explain the reversion to "TOWER". You can browse around the files in the config folder looking for corruption, the vast majority of the files are plain text, notable exceptions would be the .key file and super.dat.

 

Follow the online directions for resetting the password, and you should be good to boot back up, if you have a flash backup you can use the config folder from the backup as reference files to fix any corruptions found.

 

I've personally dealt with something very similar on one of my machines a few years ago, when it happened to me the only corrupted file was the ident.cfg, but you probably should poke around and check other files just to be safe.

 

If you know how to do a binary compare, you can check the current copy against the config folder from your backup, and examine the differences found. I wouldn't mess with differences in non-text files, but all the plain text stuff is pretty easy to parse and see if it makes logical sense.

 

I think you will probably be fine based on your description of events.

Thanks you for this post, it was reassuring to read. Apologies for the late reply, I kinda blocked this out of my head because didn't want to deal with the stress of it while away.
I'll do a diff between what I can salvage from the usb drive and the latest backup - unfortunately the last backup was late last year, but it is the case you describe, that should help me with restoring the ident config file.

Marked your answer as solution for now. Thanks for the assist!

@JonathanM Hey, just checking back in: I'm happy to report that after resetting the root creds everything reverted to normal pretty much immediately - nothing else seems to have gotten corrupted, which is surprising but also a relief. Everything works as expected. Thanks for the assist!