Lost HDD smart info on DAS hardware, like temp, or Power on Hours on Proxmenux

[gpelleja]

Hello, I have a 6-bay TerraMaster DAS connected via USB-C (10Gbps), and I hadn't had any issues until now. Last night, I had to restart the DAS. I'm not sure if the problem started then or after the last Proxmenux update, but I'm no longer getting SMART values like temperature or power-on hours. In Proxmox, I can still see these values under the SMART option, and running a short SMART test works fine.
My 2 NVME shows values without any problem.

On Home Assistant with proxmox addon I can see this values

Any idea about this? I don't know if is a bug or a problem with my proxmox

[MacRimi]

Hi @gpelleja — thanks for the detailed report. The fact that Proxmox native SMART still works but ProxMenux doesn't points to which pass-through mode is being tried under the hood.

To narrow it down, could you run these on the host and paste the output? All read-only. Use whichever letters your DAS drives show under /dev/ (replace sdX).

1) How the drives are attached and their flags:

lsblk -o NAME,TYPE,TRAN,VENDOR,MODEL,SIZE,RM

2) What smartctl auto-detects, and what each pass-through returns for one affected disk:

smartctl --scan
smartctl -a /dev/sdX
smartctl -d sat -a /dev/sdX

3) The sysfs path for that disk (tells us how ProxMenux identifies it as USB):

readlink -f /sys/block/sdX

4) Anything the Monitor logged for SMART lately:

journalctl -u proxmenux-monitor -n 300 --no-pager | grep -iE "smart|temperature|sdX"

5) The ProxMenux Monitor version — visible in Settings → About in the UI, or from the shell:

grep '"version"' /usr/local/share/proxmenux/monitor-app/web/package.json

Redact any hostnames or serials you'd rather not share publicly. With those outputs we should be able to tell whether your enclosure needs a specific pass-through type that isn't being tried, or whether something else shifted after the DAS restart.

[gpelleja]

Hello,

Thanks for the quick response.

I attach a file with all the outputs, sda to sdf are on the same DAS and have the same problem, so I only put the results form sda to not make a long output. If you need more info from the other disks, y can attach the results.

Best Regards
output.txt

[MacRimi]

Hey @gpelleja — thanks for the thorough output, this pretty much pinned it down. smartctl on your host is working fine (both plain and -d sat return everything), and the DAS is correctly seen as USB via sysfs. What I suspect is happening is on my side: the Monitor prepends three -d snt* variants (drivers meant for USB-NVMe bridges) whenever it detects a USB disk, and on your USB-SATA enclosure those probably answer with the bridge identity instead of the real disk — which then gets locked into cache and hides temperature/POH forever after.

To be sure that's exactly it, could you run these three and paste the first ~30 lines of each? Just want to see whether the ASMedia/JMicron/Realtek probes actually return anything for /dev/sda:

smartctl -a -j -d sntasmedia /dev/sda 2>&1 | head -30
smartctl -a -j -d sntjmicron /dev/sda 2>&1 | head -30
smartctl -a -j -d sntrealtek /dev/sda 2>&1 | head -30

If any of them come back with a JSON model_name or serial_number, that's the smoking gun. The fix is small once we confirm it.

[gpelleja]

Hello @MacRimi,

None of the above commands shows any json with model_name or serial_number, with or without first 30 lines filter.

I've made some research with AI knowing the DAS have an ASMedia chipset, and with this command I get the model name and serial number of the sda.

smartctl -a -j -d sat /dev/sda 2>&1 | head -40

Hope this is useful for you

Best Regards

output smartctl.txt

[MacRimi]

Hey @gpelleja — thanks for going the extra mile with those three tests, that's exactly the smoking gun. All three -d snt* return nothing on your sda because those drivers are NVMe-Storage-Namespace-Transport (for USB-NVMe bridges only), and your DAS is USB-SATA — the ASMedia bridge just doesn't speak that protocol. Meanwhile -d sat returns everything, as you found.

What was happening on the Monitor side: I was prepending the three -d snt* probes for every USB disk regardless of whether it was NVMe or SATA. On your DAS each of those wasted ~5 s waiting for a response that never came, and by the time the cascade got to the plain smartctl -a -j fallback the failure backoff had already kicked in — so temperature and POH silently disappeared even though the disks were fine.

Fix on the way in the next beta: the -d snt* variants now only try on nvme* kernel nodes. sd* USB-SATA (your case, TerraMaster DAS with HDDs, USB HDD/SSD enclosures) goes straight to the working smartctl -a -j path. Temperature, power-on hours, model, serial and health should all come back at the first poll after the update, no manual step needed.

The temperature history graph will have a gap for the days the probe was failing (the sampler was writing null values), but the previous history stays intact and it'll pick up fresh samples from the new build onwards.

Thanks again for the patience and the clean diagnostic — this class of ASMedia-SATA bug wouldn't have been obvious without the -d snt* output you captured.

[gpelleja]

Hi,

Thanks for your quick response and for all your work.

Best regards