jdubbs23

Either way I didn't have the localhost IP specified and now it works, thanks!

Thank you kind sir! My research indicated something power-related or RAM-related as well. I will do the memtest. I have a bunch of components all connected on the same circuit and nothing else shows a restart and I don't see any other evidence of a power failure. I don't have the array auto-start because I use encrypted disks and a passphrase to restart. I believe (research on this was years ago) there wasn't a secure way to get the passphrase to unraid for autostart, so I just live with manual array starts. I also found the syslog server during my research this morning, that seems quite useful and I didn't know about it. I enabled it and just picked an existing share like appdata for now. However, I don't see the syslog file being created there. I manually forced some messages to the logger and I can see them in the actual syslog, but not in the new location I specified. Do I need to restart unraid after enabling the syslog server to get it working?

Hi, I woke up this morning (late, due to no alarm) and realized pretty quickly Home Assistant wasn't running. In fact, my unraid array wasn't started, and so all my Dockers weren't running. It looks like the unraid server rebooted itself just before 4 AM. My mover runs nightly at 2 AM, and my backups run on Mondays so it wasn't that. How can I go about diagnosing what caused this? I grabbed a diagnostic log before i started the array, not sure if it would help. tower-diagnostics-20250307-0759.zip

Ugh, another disk went disabled and not sure why (sdb). Can you take a look at this diagnostics before I stop the array and shut down again? tower-diagnostics-20220918-1039.zip

Thank you so much for your interpretation of my diagnostic files and your help!

Finally got around to checking the cables and restarting. The SMART is there now. Does the drive seem OK? If so what do I do to re-enable things? tower-diagnostics-20220905-1527-array-start.zip

We had a power failure over the weekend and I just got around to starting my array again. It required a parity check upon restart and during the parity check (read-check) I got disk errors from one disk. Not sure how to tell if this is a real disk failure situation or something that can be ignored because of the recent power failure. Thanks in advance for any help/insight. tower-diagnostics-20220822-1357.zip

Well I feel like an idiot, but that was the wrong drive. What got me thinking about it was the size (not typical SSD size), and after running the fdisk utility the name (spinpoint) made me think of a spinning drive and I knew I had an SSD for the cache. So it seems that something happened with the PCIe adapter board that the SSD is connected to, because I opened the case and reseated it and then the drive showed up, I assigned it to cache, and all is fine. Thanks to @trurl and @JorgeB for all the help troubleshooting this with me, and sorry for the incorrect info and my mistakes/forgetfulness.

Yes I would format the current cache drive and add it back into the array and then do the restore. Just wanted to confirm this course of action. Is there something about the drive I was using for cache that could be failing and why the partition is gone?

Well I did use the CA Backup and Restore plugin, so I can see I have a backup of Appdata from 11/27 along with flash and system. I guess the VMs needed to be backed up manually so I just see one of the VMs there from 1.5 years ago (must have did a manual one then). So should I do a restore of the Appdata to at least get Dockers back? I guess the VMs are gone.

That's what I mean, I'm the only one that accesses the array and obviously didn't delete the partition, so I don't understand how this could happen.

Any idea how this can possibly happen? A fully functional array that isn't even being used most of the time just randomly deletes a partition on the cache drive?

OK Here is the diagnostics with the array started and the cache drive unassigned. I can't do anything with it in unassigned devices: root@tower:~# fdisk -l /dev/sdm Disk /dev/sdm: 298.09 GiB, 320072933376 bytes, 625142448 sectors Disk model: SAMSUNG HD321KJ Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@tower:~# tower-diagnostics-20211210-1012.zip

Appreciate you looking into this for me, just wondering if you had any other suggestions. I don't want to lose the data on the flash drive, but I'm not sure how to go about recovering or if there is anything even wrong or if it just some config issue that got messed up.

Is it safe to start the array with the drive reassigned back to the cache slot? I wasn't sure, but can do that and restart the array. I can't remember if I did encryption for the cache drive when I went through the whole process to encrypt the drives. I want to say that I remember not encrypting that one but I can't be sure. When I reassigned the drive to the cache slot it didn't give me any prompts about filesystem or encryption or anything. I had already passed the passphrase to unraid during the first array start after the reboot so I figured the cache drive would use that passphrase if the FS was encrypted.

Ah ok sorry, and thanks for your help with this. Just to clarify: when I first went to the server and discovered I couldn't start the Dockers I did a restart with no diagnostics (I realize that was wrong). Then upon the restart I just started the array and didn't take a close look at the drive assignments but captured the diagnostics then, that is what I attached to first post. While the array was started I noticed the cache drive was in unassigned devices and there was effectively no cache drive. I stopped the array and then reassigned the cache drive to the cache slot. I didn't see any warnings about data loss, and it said "configuration is valid" so I started the array again. Upon this array start with the cache drive in place I see the btrfs error from the screen cap. I got nervous so I stopped the array again and here we are. Attached is the latest diagnostics from where I am currently (step 5). tower-diagnostics-20211208-1021.zip

It was attached to my first post? tower-diagnostics-20211207-2139.zip

OK I noticed my cache drive was in unassigned devices for some reason. I stopped the array and looked at the config and it wasn't assigning the cache drive to the cache slot. So I assigned it back in, started array and it says it can't mount it:

Server has been up for days/weeks/months not really sure, but haven't been on it in a few days. Logged in today to start a Docker container and got a Server Error pop up window. Tried a few other Dockers as well and same issue. VMs were all fine. Did a restart and now all Dockers are gone along with all VMs. Appdata folder is empty. tower-diagnostics-20211207-2139.zip

Thanks for the work on this @saarg, much appreciated over the years! I will check out the other options or maybe just run it myself in my Linux VM.

Thanks for the update and the work you do for this container. Maybe I'm doing something wrong on my end because still not getting it to work. Is there something I could check to see? Do you mean you might not update the MakeMKV container or the base ubuntu distribution you have for running MakeMKV?

Just saw an update was available. After applying though still get the black screen.

Is there an update to the docker? Unraid isn't showing anything.

I just did the latest update that showed today, and now when I try to go to the WebUI it shows the xrdp session but when I select OK I just get a blank screen. How can I diagnose this?

Nevermind. Read back several pages and found that it was likely due to setting a different (or no) password when I created the mariaDB Docker. I nuked the mariaDB and nextcloud dockers and made sure to set a mariaDB password when I first installed the docker. Then everything went correctly when creating the admin user in nextcloud's web interface.