I was working on setting a security cam up to record via sftp.    I didn't seem to be working, but the next morning all of my disks are offline and unable to start.   Looking through the forums I see similar issues due to /root being full.  Sure enough that was the issue and clearing the files allowed everything to come back online.   I had a lapse of judgement and started wondering why the files were in the root directory to begin with.   Well, they were in a subdirectory under root ( root/mnt/user0/xxxx/yyy/files here).    After moving the files I was thinking that I possibly mapped the path wrong from the camera and that's the reason it was writing under root.   With that though, I gave it the ole `rm -rf mnt`  from inside the root dir.  I was hands off for a day and when attempting to login back in to the gui it was unavailable, but still able to ssh.  Going back and looking at the setup I used on the camera, I used the root user/pass to auth via ssh (sftp) to have the video saved to a specific path.    The path I had it configured to save to was (xxxx/yyy/).    

 

I'm pretty well versed in linux in general but. not Unraid.   I'm assuming that /mnt is mapped from /root/mnt and me blowing away what I thought was an illicit directory was indeed the one that should not have been deleted.    

 

Is there any hope of a recovery?   Of course, the main concern is getting access to my content back, but I'd also like to not have to reconfigure everything from the ground up as well.  

 

Dignostics attached.    Please let me know if there are any questions that I can answer to help clarify any idiotic steps I took.

 

 

tower-diagnostics-20220607-0801.zip

47 minutes ago, dumb_dumb said:

pretty well versed in linux in general but. not Unraid

Here is what you need to understand before thinking about Unraid as linux.

 

The Unraid OS is unpacked fresh from the archives on flash into RAM at each boot, and runs completely in RAM. Think of it as firmware. Settings you make in the webUI are also stored on flash so they can be reapplied at boot.

 

All of the usual linux folders are in RAM, the disks and user shares are mounted at /mnt, and the flash drive is mounted at /boot.

 

Have you rebooted since your command line adventures?

Yes, I performed a reboot from the terminal but read that doesn't do much but boot you from the session so I power cycled the box.

attaching a second diagnostic file taken after the power cycle.

 

tower-diagnostics-20220607-1845.zip

Start the array and post new diagnostics.

Doesn't look like you have assigned any disks yet. Is that correct?

I had a cache drive and 4 disks configured prior to my boo boo.   Currently I can't access the gui over 80 or 443, as if the server isn't on.   

nginx is running

 

 

root@midget:/mnt# ps -ef | grep nginx
root      4707     1  0 18:50 ?        00:00:00 nginx: master process nginx
root      4711  4707  0 18:50 ?        00:00:00 nginx: worker process
root      4715  3578  0 18:50 pts/0    00:00:00 grep nginx

Unclear what you have done unless you somehow deleted files in /boot, which would have contained your configuration on flash.

13 minutes ago, trurl said:

Settings you make in the webUI are also stored on flash so they can be reapplied at boot.

 

All of the usual linux folders are in RAM, the disks and user shares are mounted at /mnt, and the flash drive is mounted at /boot.

 

You talk about a folder named root, but that would only be the folder for the root user, which is in RAM just like everything else. Not directly related but you should also note that only root user has access to the command line and webUI. All other users are strictly for network access to storage.

 

Unraid is a NAS OS with docker and VM hosting. It isn't intended to be a general purpose, multiuser linux. If you need that you can create a VM.

 

 

Do you know your disk assignments?

1 hour ago, dumb_dumb said:

pretty well versed in linux in general

Probably better to not rely on that until you get a better idea of the differences

ls -lathr /boot
total 248M
drwx------  8 root root 4.0K Dec 31  1969 ./
drwx------  3 root root 4.0K Dec  4  2021 .Spotlight-V100/
drwx------  3 root root 4.0K Dec  4  2021 EFI/
-rw-------  1 root root  20M Dec  4  2021 bzfirmware
-rw-------  1 root root 4.6M Dec  4  2021 bzimage
-rw-------  1 root root   65 Dec  4  2021 bzfirmware.sha256
-rw-------  1 root root   65 Dec  4  2021 bzimage.sha256
-rw-------  1 root root  12M Dec  4  2021 bzmodules
-rw-------  1 root root   65 Dec  4  2021 bzmodules.sha256
-rw-------  1 root root 142M Dec  4  2021 bzroot
-rw-------  1 root root  70M Dec  4  2021 bzroot-gui
drwx------  2 root root 4.0K Dec  4  2021 syslinux/
-rw-------  1 root root 147K Dec  4  2021 memtest
-rw-------  1 root root 2.4K Dec  4  2021 make_bootable_mac
-rw-------  1 root root 3.3K Dec  4  2021 make_bootable_linux
-rw-------  1 root root 1.8K Dec  4  2021 make_bootable.bat
-rw-------  1 root root 7.8K Dec  4  2021 license.txt
-rw-------  1 root root  19K Dec  4  2021 changes.txt
-rw-------  1 root root   65 Dec  4  2021 bzroot.sha256
-rw-------  1 root root   65 Dec  4  2021 bzroot-gui.sha256
-r--------  1 root root  68K Dec  4  2021 ldlinux.sys
-r--------  1 root root 120K Dec  4  2021 ldlinux.c32
-rw-------  1 root root    0 Dec 12 10:58 .DS_Store
drwx------  3 root root 4.0K Jan 25 11:17 .Trashes/
drwx------ 10 root root 4.0K Jun  7 13:18 config/
drwx------  2 root root 4.0K Jun  7 18:45 logs/
drwxr-xr-x 20 root root  420 Jun  7 18:45 ../

would one of these file contain the disk mapping?

Throwing this into the mix as well.   I found an older version of diagnostic ran a few months back.

midget-diagnostics-20211213-1745.zip

55 minutes ago, dumb_dumb said:

would one of these file contain the disk mapping?

Everything about your configuration is in the config folder on flash; super.dat contains the disk assignments, but isn't plaintext. You must always have a current backup of flash, or at least the config folder since it is all you need to get your configuration back on a new install.

 

That diagnostic is also without the array started. You can see the assignments of the attached disks in the smart folder of those, but disk1 isn't there. Was there a disk1?

I notice in these diagnostics your server is named midget, but those previous diagnostics it had the default name tower, so that suggests you wiped out your configuration.

Also your tower diagnostics has 0 length go file, which is supposed to be the script to start the webUI. Probably your license .key file is gone too. Was it a trial key?

 

If you don't have a config backup you will have to start from a new install with no configuration (all settings from the webUI) and try to assign your disks as they were before. Maybe you didn't accidentally delete any of their contents.

 

 

2 hours ago, dumb_dumb said:

Looking through the forums I see similar issues due to /root being full

Typically what we are talking about is the root folder of the OS (in RAM), which is / (not /root). If you fill / (rootfs) the OS can't work with its files anymore.

I pulled the usb drive and did a clean install of 6.9.2 after copying the config directory to a local drive.    I didn't see your note about a 0K go file until I copied it back to the fresh install.    I got the gui running using 

/usr/local/sbin/emhttp &

 

Everything looks as it did, even containers are running.   Is it possible to write a new go file in the terminal?  

 

I'm assuming if it just starts the web service it would just be a shell script.  Something like below, possibly #!/bin/sh instead of bash.    Also, should there be a file extension, .sh or such?
 

#!/bin/bash
/usr/local/sbin/emhttp &

 

The default go file is part of a new install, you should be able to get it from the config folder of the download.

 

2 minutes ago, dumb_dumb said:

even containers are running

but without your config, you can't work with them from the webUI since you don't have their templates. You will have to install them again, if you make each of their settings the same as before they will continue to work as before.

I copied over the config directory from one of the older diags I had.   I'm able to interact with the containers with no issues.   I greatly appreciate the time and help you have provided and I think I can call this one case closed for now.