FlamongOle

Cannot do anything with that information. Please send me Disk Location debug file and also PHP logs from Unraid. Also share with me if you did something else before the problems happened. In System tab: Enable debug, then press Force SMART+DB, cancel it if it doesn't do anything withing 5 seconds, disable debug, then send me the file. Or uninstall it.

Update 2026.07.08 Commit #511 - BUG: Physical assignments wont move with the groups. Added physical.json into the rewrite loop with locations.json.

Update 2026.07.07 - Physical tray assignments has arrived! Commit #506 - FEATURE: Physical assignment of trays. Some devices can be used to assign a tray to a physical address. Using this will automatically replace drives added to that tray. Device path are assigned to trays instead of device name and serial number. READ THIS BEFORE USE OF THE NEW FUNCTION: Some devices can be used to assign a tray to a physical address. Using this will automatically replace drives added to that tray. Device path are assigned to trays instead of device name and serial number. This requires a drive to be attached and assigned before it can be used. IMPORTANT! If there is a system change with e.g. HBA/SAS card (even motherboard PCI-slot), SAS-SATA breakout cables or motherboard, the physical locations must be wiped and reconfigured in the plugin. Using HBA/SAS cards in a fixed PCI location should normally use the same addresses. If such a major change is required and you want to preserve the tray locations: Press "Save" on "Tray Allocations" page to update the manual location database. go to the "System" tab and create a backup. then wipe ONLY the "physical" configuration BEFORE doing the changes. Hot swapping requires execution of Force SMART+DB, and will be prompted within 5 minutes. Inserting devices in powered off mode, will automatically execute it during boot. This text is also found under "Help" section in the plugin. ADDITIONAL INFO: This function is optional, if you don't want to opt in, you never have to. To assign physical locations, each location must be assigned and "physical" checkbox must be marked per drive. Drives not compatible will be disabled (e.g. NVME drives). POSSIBLE FUTURE PHYSICAL LOCATION TEMPLATES: It might be possible to make location templates from original server systems, like the 45 Drives Unraid system but also others. To create such templates for me, I would need this from you, everything below is mandatory and must be completed as written: Information about the server/enclosure name and model including HBA/SAS card name and model. All trays must be filled with drives and recognized in the plugin. All tray locations must be saved how it physically looks like on the server. Physical checkbox must be marked and saved. Then send me this file: /boot/config/plugins/disklocation/physical.json DO NOT SEND ME FILES FROM NON-ORIGINAL CONFIGURATIONS!!!

Should work now, forgot to increase the version number in the install file. After "Force SMART+DB", you can manually spin down drives, then run just "SMART" afterwards to see if it behaves as expected.

Update 2026.07.06 Commit #507 - BUG: SMART data gets saved even if it's empty. SMART data got pulled when there's nothing to fetch. Checks if SMART is available and enabled before saving new SMART json files. @Lean_ try this update. You must do a SMART+DB to fix the database before we know.

I still scratch my head with this one, I might have a workaround to fix this, but I need to attack it on the right side. Can you please fetch me one json file of the "failed/flashing" devices from /tmp/disklocation/smart/ and post/send me?

The reason I want the output of the commands is that I need to see if there's something strange coming out of it. Disk Location is not supposed to pull any SMART data from sleeping devices, and does normally just use the formerly saved data. It literally checks the state of a drive before pulling the data in auto-mode.

Do you have any power settings that forces the disks to turn off, like backplate or HBA configuration of some sort? Any deep sleep functions or whatever they might be called? I'm not sure if some controllers that do these things can temporary store the SMART data while the drives are off, so it can always be pulled regardless of disk state while others do not. Just guessing here. If that SMART data cannot be collected from specific devices, then it will be known as "failed" as that is more likely cause if that data would suddenly be gone. As long as it works initially when doing like "SMART+DB", then it will force wake all drives before pulling the SMART data and it stores them. Later it will run SMART collecting on IDLE/ACTIVE drives. What might be interesting to see, is what state the "failed" drives are in (if it reports, active, idle, standby, off, anything else). You can try to pull that information running (change the sdX to whatever drive that shows failed SMART): smartctl -n standby /dev/sdX | grep -i DeviceRerun the command above after SMART+DB update, it will wake up all the drives if they are sleeping. Typically you should see something like: Device is in IDLE_A mode

Can you post me the output of: cat /var/local/emhttp/monitor.ini | grep .ackI would also like to know what's the name of the other pool if you're using it combined with "flash"/internal boot. Thanks

New function and feature in the making: assigning physical slots to device path. This will automatically replace drives in the assigned positions. This function will be experimental, and not all devices are supported. There's no ETA on completion and just a vague idea is made in the development version. It will also be optional to use this per device (see attached picture). Current help text: Some devices can be assigned to be attached to a physical address, using this will auto-replace devices added to that slot in the future. Device PATH are assigned to tray slots instead of device name and serial number. WARNING! If a SAS card, SAS-SATA breakout cables, motherboard has changed or HBA PCI position swap has been done, the physical locations must be reconfigured in the plugin! This function will always be experimental due to endless possible configurations out there. Using HBA cards in a fixed PCI location should keep the same addresses.

Update 2026.06.22 Commit #504 - BUG: Power_On_Hours from SMART fails when too high numbers are entered. Added and parses an extra "string" value if the two others default fails, otherwise leave empty. @chasteencs Please try this update (you might have to do a Force SMART+DB as well, but I don't think it should be necessary).

There's something odd with this drive, the raw[value] and power_on_time[hours] are both far off, while the raw[string] contains probably the actual hours (29807) with some extra numbers behind. I'll see if I can make a workaround for this one day when I have time. Only workaround for Disk Location now is to pull out the drive :P "id": 9, "name": "Power_On_Hours", ... }, "raw": { "value": 175874615833711, "string": "29807 (159 245 0)" // - value 2: "power_on_time": { "hours": 829080826 },

Thanks, can you also give me the output (file) of this: smartctl -x --json /dev/sds &> /tmp/smart_sds.jsonI'm trying to figure out what's going on here, because the 29807 power on hour looks fine. I just wanna see if the json outputs something else or multiple values or something. Thanks.

There's something wrong with the SMART "power on hours" on device "sds", "ST8000NC0002-1XX112", SN: ZA1091VX [powerontime] => 829080771 This means "26 years, 3 months, 7 days" power on time. I don't think any 8TB drives existed 26 years ago :P Can you please give me the output of: smartctl -a /dev/sds | grep Power_On_HoursI need to check if your HDD outputs wrong values, or if something happens with the plugin. Thanks.

I can't replicate the issue, config look fine. Can you check the PHP logs if there's any error messages related to the plugin there?