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.