Thx And Bye

I am not sure if this has come up before, but I could not find anything on it. BackgroundWhen ZFS or BTRFS is used in the array, the filesystem can detect invalid data blocks. ProblemIn cases where a block is identified as invalid, writing corrections to parity does not provide a benefit. At the same time, wiping and rebuilding an entire drive is often impractical and time-consuming. Proposed SolutionIntroduce an option to select a specific drive and run a parity check that corrects that drive, similar to the existing “write corrections to parity” functionality. EnhancementTo make the process more effective, the system could: Run a scrub when errors are detected. Based on the scrub results, automatically recommend whether corrections should be written to data or to parity.

It does indeed list one value there for the drive (Reallocated_Sector_Ct is 1) but as unRAID shows "No Attributes Available" for the flash there is no way to acknowledge the error. This SSD is quite old already and also connected via USB. So I'm not sure if it's because of the age, the connection or UnRAID not knowing how to deal with this situation (the flash having attributes in the first place). Starting S.M.A.R.T tests for the flash also doesn't seem to work. Smartctl is seemingly able to read the values, albeit not absolutely correctly since 109 years of power on time doesn't seem plausible to me.

With all drives working now, the plugin is showing the status on the dashboard as expected. One odd thing (but nothing critical): My flash is showing a S.M.A.R.T warning while the drive itself reports S.M.A.R.T as passed based on an Attribute check. I understand that a SATA SSD attached to a USB<->SATA adapter isn't the usual setup for the flash. Just an odd thing I've noticed. IB-245-C31-20250515-2100.txt

So I think I now know what the issue is. After the update to UnRAID 7.1.x the drive didn't show up anymore at all. So its likely that the drive has failed. I don't know why the SSD didn't show up the the UI of unRAID as failed though. After the update and subsequent reboot the device doesn't show up in the list and unRAID UI anymore. This also means that the plugin is not showing the error anymore and lists the configured slot as unpopulated. I have a replacement drive ordered and will report back if it shows up correctly in the plugin now too.

I've just now fond the time to run the steps with debugging. I've reset devices first and then ran SMART+DB again with debugging enabled. I've send you the .log file via PM.

nvme1n1 is missing. That would be the MKNSSDTS1TB-D8_MK23021714C44E8B3.json (file attached) Sorry that I didn't check earlier there is this error in the log (but nothing on the 16th when I initially tried to setup the plugin): [29-Apr-2025 00:00:01 Europe/Berlin] PHP Fatal error: Uncaught TypeError: end(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/disklocation/pages/page_system.php:414 Stack trace: #0 /usr/local/emhttp/plugins/disklocation/pages/page_system.php(414): end(false) #1 {main} thrown in /usr/local/emhttp/plugins/disklocation/pages/page_system.php on line 414 MKNSSDTS1TB-D8_MK23021714C44E8B3.json

[2025-04-16 23:07:23] SMART: /dev/sg1 UNKNOWN (1b7852b855) done in 42ms. [2025-04-16 23:07:24] SMART: /dev/sg0 UNKNOWN (3f4304780f) done in 226ms. [2025-04-16 23:07:24] SMART: /dev/sg2 IDLE (ee963138ac) done in 576ms. [2025-04-16 23:07:24] SMART: /dev/sg3 ACTIVE (deb7fcf9fa) done in 331ms. [2025-04-16 23:07:25] SMART: /dev/sg4 ACTIVE (fb5b981762) done in 125ms. [2025-04-16 23:07:25] SMART: /dev/sg5 ACTIVE (626427ef2d) done in 339ms. [2025-04-16 23:07:25] SMART: /dev/sg6 ACTIVE (e51311a5b7) done in 109ms. [2025-04-16 23:07:25] SMART: /dev/sg7 IDLE (8b0e9492c0) done in 203ms. [2025-04-16 23:07:25] SMART: /dev/sg8 ACTIVE (53d30157b3) done in 97ms. [2025-04-16 23:07:26] SMART: /dev/sg9 ACTIVE (9c84f2f252) done in 183ms. [2025-04-16 23:07:26] SMART: /dev/nvme0n1 ACTIVE (4a9eeecc90) done in 75ms. [2025-04-16 23:07:26] SMART: /dev/nvme1n1 ACTIVE (1b7852b855) done in 43ms. Writing to the database... done in 2.7 seconds. In this list both NVMe drives seem to be listed. INTEL_SSDSC2CT060A3_CVMP213502QX060AGN.json ST16000NM001G-2KK103_ZL2P97RS.json TOSHIBA_MG08ACA16TE_13U0A059FVGG.json KIOXIA-EXCERIA_G2_SSD_X2EB70WHKME5.json ST4000VN008-2DR166_ZDHALT30.json WDC__WDS200T1R0A-68A4W0_23292T800029.json MKNSSDTS1TB-D8_MK23021714C44E8B3.json ST4000VN008-2DR166_ZM40Y4EY.json WDC__WUH721816ALE6L4_5EG2NW7P.json SPCC_Solid_State_Disk_AA230217S302KG00435.json TOSHIBA_MG08ACA16TE_13U0A058FVGG.json For both NVMe drives the json file do contain valid data. Should I proceed and remove the files or reset the devices? The RAM I have is ECC, so if it's corrupted I don't think it's related to the device itself. Just in case it might be important: The NVMe drives are on a bifucation card in a single x8 PCIe slot.

I've just installed this plugin and it looks promising (apart from the default colors being nearly unreadable with the "Azure" theme, but that was quickly fixed by changing the colors to lighter ones) The main issue I'm facing right now is that, after following the instructions on the dashboard and subsequently setting up the layout and assigning the disks, the dashboard just shows a Go to System and initialize a "Force SMART+DB" warning. Executing this options has no effect on the warning though. Let me know if there is anything I can provide or if this is an easy fix. The plugin also doesn't detect one of my NVMe drives. 11 drives total is correct, but under allocations there is only 10 options to select. /dev/nvme0n1p1 is detected as nvme0n1 but /dev/nvme1n1p1 isn't. regards

The output from docker ps -a.txtlooks rather normal to me. Here is the docker inspect 2eda680bcc88.txt but I can't see anything special about it either? Here is the log of the containers starting:container startup logs.txt

Yes I have CA Auto Update Applications installed. The error occurs on manual backups too though and the backup and auto update run at different times anyways. It's always the same container that has this problem (it starts just fine when doing so manually via the webUI). The container is part of a stack deployed via docker-compose (Compose Manager Plugin) and not touched by the auto update. I've also replaced my gzip with pigz for (much) faster compression, but it's likely unrelated as the creation and validation of the archives works just fine.

I'm always getting a failed backup but none of the archives failes to validate. One container failes to start because the image can't be deleted (?) though. But a container not starting correctly shouldn't fail the backup, right? backup.log

Would it be feasible to get a checkbox to run nvidia-persistenced after the driver install on system startup to keep the driver loaded? More information: https://docs.nvidia.com/deploy/driver-persistence/index.html

Yes, two of them have. plexinc/pms-docker has it build in and I've created my own that checks that my VPN container is properly connected.

For now I'm running a user script on a daily schedule as a workaround: #!/bin/bash /usr/local/bin/unraid-api/unraid-api restart