Summary
I found what appears to be a bug in the agent when using device_overrides with a Samsung T7 USB SSD.
The override is recognized by the agent, but the configured protocol is not passed to smartctl during polling.
If you'd like, I'm happy to test a development build on this hardware -
Environment
- SMART Sniffer Agent: v0.5.16
- OS: Debian Bookworm (arm64)
- smartmontools: 7.3
- Device: Samsung PSSD T7 1TB
- Device path:
/dev/sda
Discovery
Automatic discovery does not find the drive:
sudo smartctl --scan-open
returns no drives.
Manual SMART access
The drive is accessible when explicitly using the SCSI transport:
sudo smartctl -d scsi -a /dev/sda
This returns:
- SMART support available
- SMART support enabled
- SMART Health Status: OK
Configuration
I added the following override:
device_overrides:
- device: /dev/sda
protocol: scsi
Agent log
The agent recognizes the override:
added override device: /dev/sda (protocol: scsi)
However, immediately afterwards it logs:
WARNING: smartctl -a /dev/sda failed (exit code 1: command line parse error)
API output
The drive is created:
{
"id":"dev-sda",
"device_path":"/dev/sda",
"protocol":"scsi"
}
but the returned SMART JSON shows the executed command was:
smartctl --json -a /dev/sda
instead of:
smartctl --json -d scsi -a /dev/sda
The returned JSON includes:
/dev/sda: Unknown USB bridge [0x04e8:0x4001 (0x100)]
which is expected when -d scsi is omitted.
Expected behavior
When a drive is configured with:
device_overrides:
- device: /dev/sda
protocol: scsi
the polling command should include the configured transport:
smartctl --json -d scsi -a /dev/sda
instead of:
smartctl --json -a /dev/sda
That would allow SMART polling to succeed for this Samsung T7. FYI, from the RPI4 host command line:
pi@kruse-pi:~$ sudo smartctl --json -d scsi -a /dev/sda
{
"json_format_version": [
1,
0
],
"smartctl": {
"version": [
7,
3
],
"svn_revision": "5338",
"platform_info": "aarch64-linux-6.1.0-51-arm64",
"build_info": "(local build)",
"argv": [
"smartctl",
"--json",
"-d",
"scsi",
"-a",
"/dev/sda"
],
"exit_status": 4
},
"local_time": {
"time_t": 1785518199,
"asctime": "Fri Jul 31 13:16:39 2026 EDT"
},
"device": {
"name": "/dev/sda",
"info_name": "/dev/sda",
"type": "scsi",
"protocol": "SCSI"
},
"scsi_vendor": "Samsung",
"scsi_product": "PSSD T7",
"scsi_model_name": "Samsung PSSD T7",
"scsi_revision": "0",
"scsi_version": "SPC-4",
"user_capacity": {
"blocks": 1953525168,
"bytes": 1000204886016
},
"logical_block_size": 512,
"scsi_lb_provisioning": {
"name": "fully provisioned",
"value": 0,
"management_enabled": {
"name": "LBPME",
"value": -1
},
"read_zeros": {
"name": "LBPRZ",
"value": 0
}
},
"rotation_rate": 0,
"logical_unit_id": "0x5000000000000001",
"serial_number": "Y390104T0SNBX6S",
"device_type": {
"scsi_terminology": "Peripheral Device Type [PDT]",
"scsi_value": 0,
"name": "disk"
},
"smart_support": {
"available": true,
"enabled": true
},
"temperature_warning": {
"enabled": false
},
"smart_status": {
"passed": true
},
"temperature": {
"current": 0
},
"scsi_temperature": {
"drive_trip": 0
}
}
pi@kruse-pi:~$
If you'd like, I'm happy to test a development build on this hardware.
Summary
I found what appears to be a bug in the agent when using
device_overrideswith a Samsung T7 USB SSD.The override is recognized by the agent, but the configured protocol is not passed to
smartctlduring polling.If you'd like, I'm happy to test a development build on this hardware -
Environment
/dev/sdaDiscovery
Automatic discovery does not find the drive:
returns no drives.
Manual SMART access
The drive is accessible when explicitly using the SCSI transport:
This returns:
Configuration
I added the following override:
Agent log
The agent recognizes the override:
However, immediately afterwards it logs:
API output
The drive is created:
{ "id":"dev-sda", "device_path":"/dev/sda", "protocol":"scsi" }but the returned SMART JSON shows the executed command was:
instead of:
The returned JSON includes:
which is expected when
-d scsiis omitted.Expected behavior
When a drive is configured with:
the polling command should include the configured transport:
instead of:
That would allow SMART polling to succeed for this Samsung T7. FYI, from the RPI4 host command line:
If you'd like, I'm happy to test a development build on this hardware.