dumb_dumb

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.

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 &

Throwing this into the mix as well. I found an older version of diagnostic ran a few months back. midget-diagnostics-20211213-1745.zip

would one of these file contain the disk mapping?

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 ../

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

attaching a second diagnostic file taken after the power cycle. tower-diagnostics-20220607-1845.zip

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.

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