Collector cannot monitor QNAP TR-004 using smartctl jmb39x-q backend

[evanmac]

Issue Description

ssue Description

I'm trying to monitor the disks of a QNAP TR-004 enclosure in Individual mode using the latest Docker image of Scrutiny (dev-0.9.2).

After some investigation, I found two independent issues.

1. jmb39x-q,N device type is parsed incorrectly

The correct smartctl backend for the TR-004 is:

smartctl -x --json -d jmb39x-q,0 /dev/sdc

However, when configuring the collector as:

devices:
  - device: /dev/sdc
    type: jmb39x-q,0

the collector executes:

smartctl --info --json --device jmb39x-q /dev/sdc
smartctl --info --json --device 0 /dev/sdc

instead of:

smartctl --info --json --device jmb39x-q,0 /dev/sdc

As a result, the device cannot be identified correctly.

2. Valid SMART JSON is discarded when using the correct backend

If I force the collector to use:

jmb39x-q,0

Scrutiny creates the device, but it is shown as "No Data".

Running the command manually on the host:

smartctl -x --json -d jmb39x-q,0 /dev/sdc

returns a complete JSON document containing:

model
serial number
SMART attributes
temperature
power-on hours
reallocated sectors
pending sectors
etc.

However, the generated JSON contains:

"exit_status": 4

because smartctl reports:

Read Device Statistics page 0x00 failed

This is only a warning. The SMART data itself is complete and usable.

It appears that Scrutiny rejects the JSON because of the non-zero exit status instead of parsing the available SMART information.

Expected Behavior

Preserve jmb39x-q,0 as a single --device argument.
Accept and parse valid SMART JSON returned by smartctl, even when exit_status = 4, since the SMART data is present and complete.

Actual Behavior

When configuring a QNAP TR-004 disk using the correct smartctl backend (jmb39x-q,N), Scrutiny does not successfully collect SMART data.

There are two observable behaviors:

1. If the collector configuration uses:

type: jmb39x-q,0

the collector incorrectly splits the backend into two separate --device arguments:

smartctl --info --json --device jmb39x-q /dev/sdc
smartctl --info --json --device 0 /dev/sdc

instead of:

smartctl --info --json --device jmb39x-q,0 /dev/sdc

If the collector is forced to use the correct backend, Scrutiny creates the device entry but displays it as "No Data".

The manual command:

smartctl -x --json -d jmb39x-q,0 /dev/sdc

returns a complete JSON document containing all SMART attributes (temperature, power-on hours, reallocated sectors, pending sectors, etc.).

However, because smartctl returns:

"exit_status": 4

(with warnings such as Read Device Statistics page 0x00 failed), Scrutiny appears to reject the result instead of parsing the valid SMART data contained in the JSON.

As a result, the device is detected but no SMART information is displayed in the web interface.

Reproduction Steps

1. Install Scrutiny using the latest Docker image:

image: ghcr.io/analogj/scrutiny:latest

2. Connect a QNAP TR-004 enclosure configured in Individual mode.

3. Verify that smartctl can successfully read SMART data from the host:

smartctl -x --json -d jmb39x-q,0 /dev/sdc

The command returns a valid JSON document containing complete SMART information (temperature, power-on hours, SMART attributes, etc.).

4. Configure collector.yaml as follows:

devices:
  - device: /dev/sdc
    type: jmb39x-q,0

5. Run the collector manually:

docker exec scrutiny scrutiny-collector-metrics run

6. Observe the collector logs.

Instead of executing:

smartctl --info --json --device jmb39x-q,0 /dev/sdc

Scrutiny executes:

smartctl --info --json --device jmb39x-q /dev/sdc
smartctl --info --json --device 0 /dev/sdc

which causes device detection to fail.

7. If the collector is modified to force the correct backend, the device appears in the web UI but is displayed as "No Data", despite the fact that smartctl returns a complete SMART JSON document for the same disk.

scrutiny debug logs

No response

Scrutiny Version

v0.9.2

Smartmontools Version

7.4

OS Version Information

Debian 13

Component

collector

Deployment Method

• docker
• binaries
• systemd

Hard Drive Information

No response

smartctl output

No response

docker-compose.yml

No response

scrutiny.yaml

No response

collector.yaml

No response

Additional relevant configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the scrutiny repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[kaysond]

Thanks for the detailed report.

If the collector is modified to force the correct backend, the device appears in the web UI but is displayed as "No Data", despite the fact that smartctl returns a complete SMART JSON document for the same disk.

Can you please post the debug logs from the collector and web when you do this? Scrutiny should still send the data even if smartctl returns non-zero

[kaysond]

How are you forcing the -d argument? Drives are added to the db after smartctl info, but data gets added after smartctl -x. If you're using the collector.yml settings, you have to update both.

[evanmac]

How are you forcing the -d argument? Drives are added to the db after smartctl info, but data gets added after smartctl -x. If you're using the collector.yml settings, you have to update both.

Thanks.

At the moment I'm only using the collector.yml device configuration.

Could you clarify what you mean by "update both"?

I assumed the device type configured in collector.yml would be used for both the smartctl --info and smartctl --xall calls.

If there is a separate configuration for the --info and --xall device arguments, could you point me to the expected syntax?

[evanmac]

While looking through the source I noticed something that may help.

The configuration tests already contain sat,auto as a valid single device type:

TestConfiguration_GetScanOverrides_DeviceTypeComma

which suggests that comma-separated smartctl device types are intentionally supported.

However, during detection the collector ends up executing:

--device jmb39x-q
--device 0

instead of:

--device jmb39x-q,0
I'm currently looking into detect.go because it looks like the device type is being split somewhere after the configuration has already been parsed correctly.

[evanmac]

I found the issue.

The problem was not Scrutiny itself, but my collector configuration.

For device types containing commas (like jmb39x-q,0), the value must be specified as a YAML list.

This does NOT work:

devices:
  - device: /dev/sdc
    type: jmb39x-q,0

This works correctly:
devices:

- device: /dev/sdc
   type:
     - "jmb39x-q,0"

After changing all four QNAP TR-004 drives to:

devices:
  - device: /dev/sdc
    type:
      - "jmb39x-q,0"

  - device: /dev/sdd
    type:
      - "jmb39x-q,1"

  - device: /dev/sde
    type:
      - "jmb39x-q,2"

  - device: /dev/sdf
    type:
      - "jmb39x-q,3"

the collector correctly executes:

smartctl --info --json --device jmb39x-q,N
smartctl --xall --json --device jmb39x-q,N

and all SMART attributes, temperatures, power-on hours and health information are correctly displayed for every drive in the TR-004.

The remaining "smartctl returned error code (4)" messages are expected because the JMB39x bridge does not implement every optional ATA command, but the SMART data itself is complete and Scrutiny imports it correctly.

Thanks for pointing me in the right direction.

[kaysond]

This is really unintuitive... I'll have to take a look and see why that's expected.