SMART Alert Reports Wrong Drive Information (S/N and Model)

[SGr33n]

Hi,

I'm reporting an issue where smartd uses cached device information when a device path gets reassigned to a different physical drive, leading to incorrect device identification in alert emails.

I initially reported this to Proxmox VE (​https://bugzilla.proxmox.com/show_bug.cgi?id=6875) but they confirmed it's a smartmontools behavior that should be addressed upstream.

Here's what happened: My Proxmox host has a SATA controller with PCIe passthrough to a TrueNAS VM. During boot, smartd scans all devices including a 16TB Seagate ST16000NM000J on that controller. After boot, the controller is passed through to the VM. Later, I connected a 4.5TB USB drive with SMART errors that appeared as /dev/sda.

When smartd detected 2435 pending sectors on /dev/sda, the email alert showed the serial number, model, and capacity of the Seagate drive instead of the actual USB drive. The Seagate was never /dev/sda on Proxmox - smartd just cached its information during the initial scan and reused it when a different drive appeared at that path.

This is problematic because administrators might replace the wrong drive based on incorrect serial numbers, while the actually failing drive goes unnoticed. Device paths like /dev/sdX aren't stable identifiers, and smartd should either detect when a device has changed (via WWN/serial mismatch) or re-query the device before sending alerts.

As a workaround, I can configure smartd to explicitly exclude or include specific devices, but the default behavior of trusting cached information for reassigned device paths seems fundamentally unsafe for modern dynamic storage environments with hot-swappable bays, USB drives, or passthrough configurations.
Is this the intended behavior, or could smartd be made to verify device identity before using cached information?

Thanks

[Christian Franke]

Hotplug is still an open issue. Pull requests to our new upstream repo at GH are welcome:
​https://github.com/smartmontools/smartmontools

... Device paths like /dev/sdX aren't stable identifiers ...

This is not the case if DEVICESCAN -d by-id is used. This is available for Linux /dev/disk/by-id/LINK -> /dev/sdX links since smartd 7.0 (recently enhanced to /dev/nvmeN, see ​GH issues/401).

[SGr33n]

Thanks for confirming this is a known issue. I'll use the -d by-id workaround for now.

[Christian Franke]

See ​GH issues/297.