Proddy

Awesome, thanks for the quick turnaround, much appreciated

My PHP log level is set to default The GPU is an Intel Arc Battlemage B580, using the XE driver Thanks, Josh

I just created a GitHub issue, but then realised the repo seems dead, so reposting here. gpustat seems to be spamming my phplog, my system has been online for 3 days and half my log drive is taken by a phplog that's 53MB, spammed with: [16-May-2026 13:52:00 Europe/London] gpustat: qmassa path lookup result: /usr/local/sbin/qmassa [16-May-2026 13:52:00 Europe/London] gpustat: Executing qmassa command: timeout 10 /usr/local/sbin/qmassa -wxa -m 1000 -n 2 -t '/tmp/gpustat_qmassa_0000_11_00.0.json' -d '0000:11:00.0' 2>&1 [16-May-2026 13:52:00 Europe/London] gpustat: qmassa return code: 0, output lines: 1 [16-May-2026 13:52:00 Europe/London] gpustat: qmassa output has 3 lines [16-May-2026 13:52:00 Europe/London] gpustat: Device 0000:11:00.0 has 0 clients in qmassa output [16-May-2026 13:52:00 Europe/London] gpustat: Found 0 DRM clients for 0000:11:00.0 [16-May-2026 13:52:00 Europe/London] gpustat: qmassa returned no clients, falling back to sysfs for client detection [16-May-2026 13:52:00 Europe/London] gpustat: Found 0 clients from sysfs fallback [16-May-2026 13:52:00 Europe/London] gpustat: Transformed data has 0 clients [16-May-2026 13:52:02 Europe/London] gpustat: qmassa return code: 0, output lines: 1 [16-May-2026 13:52:02 Europe/London] gpustat: qmassa output has 4 lines [16-May-2026 13:52:02 Europe/London] gpustat: Device 0000:11:00.0 has 0 clients in qmassa output [16-May-2026 13:52:02 Europe/London] gpustat: Found 0 DRM clients for 0000:11:00.0 [16-May-2026 13:52:02 Europe/London] gpustat: qmassa returned no clients, falling back to sysfs for client detection [16-May-2026 13:52:02 Europe/London] gpustat: Transformed data has 0 clients [16-May-2026 13:52:41 Europe/London] gpustat: qmassa path lookup result: /usr/local/sbin/qmassa [16-May-2026 13:52:41 Europe/London] gpustat: Executing qmassa command: timeout 10 /usr/local/sbin/qmassa -wxa -m 1000 -n 2 -t '/tmp/gpustat_qmassa_0000_11_00.0.json' -d '0000:11:00.0' 2>&1 [16-May-2026 13:52:43 Europe/London] gpustat: qmassa path lookup result: /usr/local/sbin/qmassa [16-May-2026 13:52:43 Europe/London] gpustat: Executing qmassa command: timeout 10 /usr/local/sbin/qmassa -wxa -m 1000 -n 2 -t '/tmp/gpustat_qmassa_0000_11_00.0.json' -d '0000:11:00.0' 2>&1 [16-May-2026 13:52:43 Europe/London] gpustat: qmassa return code: 0, output lines: 1 [16-May-2026 13:52:43 Europe/London] gpustat: qmassa output has 3 lines [16-May-2026 13:52:43 Europe/London] gpustat: Device 0000:11:00.0 has 0 clients in qmassa output [16-May-2026 13:52:44 Europe/London] gpustat: Found 0 DRM clients for 0000:11:00.0 [16-May-2026 13:52:44 Europe/London] gpustat: qmassa returned no clients, falling back to sysfs for client detection [16-May-2026 13:52:44 Europe/London] gpustat: Found 0 clients from sysfs fallback [16-May-2026 13:52:44 Europe/London] gpustat: Transformed data has 0 clients [16-May-2026 13:52:45 Europe/London] gpustat: qmassa return code: 0, output lines: 1 [16-May-2026 13:52:45 Europe/London] gpustat: qmassa output has 4 lines [16-May-2026 13:52:45 Europe/London] gpustat: Device 0000:11:00.0 has 0 clients in qmassa output [16-May-2026 13:52:46 Europe/London] gpustat: Found 0 DRM clients for 0000:11:00.0 [16-May-2026 13:52:46 Europe/London] gpustat: qmassa returned no clients, falling back to sysfs for client detection [16-May-2026 13:52:46 Europe/London] gpustat: Transformed data has 0 clients Unsure when it started, I noticed my log drive was full and rebooted, and then it's half filled again Thanks, Josh

So I noticed my logs being spammed with: May 12 19:46:08 Unraid apcaccess: : Bogus configuration value (*invalid-cable*) I use NUT to monitor my UPS, so I have Start APC UPS daemon set to No, and I couldn't figure out what was spamming my log, so I removed execute permissions from apcaccess. After doing that, I noticed graphql-api.log is now spamming: [23:10:09 ERROR UPSService]: Error getting UPS data: {"apiVersion":"4.33.0+7af4c774","logger":"UPSService","context":"UPSService"} [23:10:09 ERROR ExceptionsHandler]: Failed to get UPS data: No UPS data returned from apcaccess {"apiVersion":"4.33.0+7af4c774","logger":"ExceptionsHandler","context":"ExceptionsHandler"} err: { "type": "Error", "message": "Failed to get UPS data: No UPS data returned from apcaccess", "stack": Error: Failed to get UPS data: No UPS data returned from apcaccess at UPSService.getUPSData (file:///usr/local/unraid-api/dist/assets/plugin.module-Bu4zPTJU.js:31482:19) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async UPSResolver.upsDevices (file:///usr/local/unraid-api/dist/assets/plugin.module-Bu4zPTJU.js:31780:25) } How can I stop the Unraid API from trying to read a non-existent APC-compatible UPS and spamming my logs? Thanks, Josh

So I now have: - 3 x 4 HDDs on one cable - 1 x 3 HDDs + 1 SSD + 1 Fan Controller on one cable (17 SATA powered devices total, but I think the SSD and Fan Controller don't draw that much, so putting them on the one with 3 HDDs makes sense to me) I've also replaced the Mini SAS -> 4x SATA cables, because I didn't want to have to get physical access to the server again (it's in an awkward place) Hopefully that's all the issues resolve, thanks for the support everyone

I think one of the cables has 5 drives on it - though it has been that way for over a year Thanks Josh

So after reseating and rebuiling, it worked fine for a couple days until I got another error last night - this time from a different disk. I've attached the diagnostics just in case, but presumably this is a connection issue as mentioned. With that in mind, is there a way to test if it's data or power? I'm using a HBA with two Mini SAS -> 4xSATA, so that could explain the different disks erroring without the entire card being dead. Thanks, Josh unraid-diagnostics-20260426-1302.zip

Ah thank you, I was looking in the wrong subsection - my mistake. That rebuild is going now. Hopefully all goes well. Thanks, Josh

I checked some other threads and saw I need to rebuild the drive onto itself, but all the links provided were dead links (https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself), and the equivalent link I found pointing to the new docs (https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#rebuilding-a-drive-onto-itself) doesn't seem to have that section either. Thanks, Josh

I shutdown, reseated everything, powered on, stopped the array, but the disk just says "disabled" - I may be blind but where do I re-enable the disk? Thanks, Josh

Thanks - the server was shutoff and moved about a week ago, so I was wondering if it had started then. What would you suggest as next steps? Power off, check/replug cables, and see if that improves anything? Thanks, Josh

Hi Brit, Thanks for taking a look. I started that after the drive disabled due to errors, and it's been stuck at 10% so I decided to post this instead of waiting potentially forever I'm unsure how far back the diagnostic logs go - do they imply when the read/write errors started occurring? Thanks, Josh

Unraid just took a disk offline due to 58 "Errors", but checking SMART all I see is Raw_Read_Error_Rate, but it hasn't even hit the threshold at its worst: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-- 100 064 044 - 0/1183016I've attached my diagnostics, is there any indication of what's actually erroring, and if the disk is completely borked and needs replacing? Thanks, Josh unraid-diagnostics-20260424-0047.zip

It might have been user error previously - I just changed back to :latest and Wireguard worked successfully, all is good

I just pulled latest, same issue: 2025-07-05 19:32:06,275 DEBG 'start-script' stdout output: [info] Configuring WireGuard... 2025-07-05 19:32:06,285 DEBG 'start-script' stdout output: [info] Attempting to bring WireGuard interface 'up'... 2025-07-05 19:32:06,292 DEBG 'start-script' stderr output: Warning: `/config/wireguard/wg0.conf' is world accessible 2025-07-05 19:32:06,298 DEBG 'start-script' stderr output: [#] ip link add dev wg0 type wireguard 2025-07-05 19:32:06,300 DEBG 'start-script' stderr output: [#] wg setconf wg0 /dev/fd/63 2025-07-05 19:32:06,302 DEBG 'start-script' stderr output: [#] ip -4 address add 10.2.0.2/32 dev wg0 2025-07-05 19:32:06,308 DEBG 'start-script' stderr output: [#] ip link set mtu 1420 up dev wg0 2025-07-05 19:32:06,311 DEBG 'start-script' stderr output: [#] resolvconf -a wg0 -m 0 -x 2025-07-05 19:32:06,318 DEBG 'start-script' stderr output: could not detect a useable init system 2025-07-05 19:32:06,334 DEBG 'start-script' stderr output: resolvconf: signature mismatch: /etc/resolv.conf 2025-07-05 19:32:06,335 DEBG 'start-script' stderr output: resolvconf: run resolvconf -u to update 2025-07-05 19:32:06,343 DEBG 'start-script' stderr output: [#] ip link delete dev wg0 2025-07-05 19:32:06,437 DEBG 'start-script' stdout output: [warn] Failed to bring 'up' WireGuard kernel implementation