Help! No Web Interface and No Dockers

[jwblant]

Still new to UNRAID, running 6.5.3. It's been running pretty well for the most part, minus some user errors in setting everything up. But today, I started a Windows 10 VM before realizing I had passed through the GPU of my Ryzen 2200G a few days ago while I was tinkering with some stuff. So I went to stop the VM and change it over to VNC when all of a sudden the server was completely unresponsive. The VM wouldn't stop and no other pages would load properly. The CPU was maxing out a constant 100% on all 4 cores and it started responding. So I decided to just kill the power and reboot it. 

 

Now, the service comes up and I can ping it, but there is no web interface and no dockers running. I can connect to SSH, and have rebooted and powered down several times to no avail. Based on another thread I found, I used the "nohup /usrs/local/sbin/emhttp" command and was able to get the web interface back. However, none of my settings where there and none of my dockers, plugins, or even the CA app were there. It was like a BRAND new instance of unraid, except all my data was still in the array. 

 

Any ideas on what in the world would just cause this to stop working?

tower-diagnostics-20180903-0834.zip

[John_M]

The first thing I'd do is check the USB boot flash for corruption in another PC. I notice from your diagnostics that there are a lot of FSCK*.REC files on it, which suggests that you've had problems with it before.

[Squid]

36 minutes ago, John_M said:

FSCK*.REC

 

1 hour ago, jwblant said:

"nohup /usrs/local/sbin/emhttp"

Your flash drive is missing the "go" file (/config/go), so the webUI will not start.  A stock go file is:

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

 

[jwblant]

I had some issues last weekend with a mother board not booting from the USB but when i swapped it out with a new MOBO it came back fine. I just figured it was the MOBO?

 

But how how would I go about checking it to see if it’s ok on another PC? And if I reinstall the software, will I lose anything?

[jwblant]

Would a missing go file cause the dockers and other settings to not load as well?

[Squid]

58 minutes ago, John_M said:

FSCK*.REC

 

1 hour ago, jwblant said:

"nohup /usrs/local/sbin/emhttp"

Your flash drive is missing the "go" file (/config/go), so the webUI will not start.  A stock go file is:

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

Yes.  Because emhttp never loads and starts the services.  All of the FSCK files means that a ton of files wound up being missing from the flash drive (this means your plugins, among settings)

[John_M]

24 minutes ago, Squid said:

Your flash drive is missing the "go" file

 

Nice catch.

[jwblant]

So is the best thing just to take the USB to another PC, reformat, and then reinstall the software on it like a brand new USB?

[trurl]

You can try to copy the config folder and restore it to a new install to get your settings back, assuming the config folder files weren't lost to corruption. At the very least you need to get your .key file for your license.

 

For future reference, you can always download a zipped backup of your flash from Main - Boot Device - Flash - Flash Backup. You should make a backup of flash anytime you make any configuration changes. It is especially important that your backup is current with your drive assignments.

 

If for some reason you can't get your config back, then a new install is going to require you to assign all your drives again. Do you know what they are? Please ask for more help before proceeding if you don't know your disk assignments.

[jwblant]

TL;DR - Backed up the flash drive, reimaged it and copied as many files over as I thought I needed. Tower booted right up with the web interface but had a stale config. Used SMART report from my diagnostics log to assign devices and then had to re-enter my settings and reload the dockers. Appears to be working now with data and docker settings intact. 

 

Details:

I actually went ahead and copied the flash to my desktop PC and reimaged the flash drive. I copied over as many config files as I could over last night but not the whole folder. I copied the key, shares config files and things like that. I didn't want to just copy EVERYTHING over since there was a chance something was corrupt. But one that was strange is that the disk.cfg (?, I think this was the name of the file) showed the serial numbers of the cache, but not the data disks. When the tower booted, the web interface came right up but I had a stale config. Luckily, I had pulled the diagnostics for this post and it had a SMART report which explicitly listed the serial numbers, sda/b/c/d/e names and the parity/disk1/etc for each of my drives. Using this, I was able to assign the appropriate drives back to their appropriate locations. If not for this, I wouldn't have attempted it since the parity drive is completely overwritten.

 

Lastly, my dockers were kinda there, but not really. They were all listed, but the icon was a question mark and I got some error about the file wasn't found. So I went and reinstalled CA and manually loaded them all back and it all came back just as it should. I also had to reinstall all my plugins, but that's not a huge deal. Overall, I think I'm in fairly good shape. Now if I can just get things to stay running.... It just seems like a different issue keeps popping up every time I look. lol

[trurl]

55 minutes ago, jwblant said:

I had pulled the diagnostics for this post and it had a SMART report which explicitly listed the serial numbers, sda/b/c/d/e names and the parity/disk1/etc for each of my drives.

Only the serial numbers are relevant for reassigning the drives. sdX can change from one boot to the next. Though it will often be the same, don't rely on it.

[jwblant]

2 hours ago, trurl said:

Only the serial numbers are relevant for reassigning the drives. sdX can change from one boot to the next. Though it will often be the same, don't rely on it.

Good point. I did, however, go off of the serial numbers themselves because I knew that wouldn't change. I didn't realize that the sdX numbers change though. Thought it was just based off the SATA port it was plugged into.