HV: Proxmox Virtual Environment 9.0.11
VM: TrueNAS Scale: 25.10.0 - Goldeye
Drives
NVME SSD: NVME WDC 64Gb - Boot drive
HDD : WD Drives Data Mirror 4Tb
SSD: Kingston SA400 120Gb
I’m trying to add the Kingston SSD as cache drive in an existing pool.
I always get this error, even though this is a separate drive with different serials
I already try to pass the serial from Proxmox to the TrueNAS vm
Do NOT pass virtual drives from Proxmox (other than the VM itself); pass through the SATA/SAS controller and NVMe drives as PCIe devices—and blacklist them in Proxmox.
Ohh I finally have the proper passthrough.
I added the entire SATA Controller to the TrueNas VM as PCI Device so the TrueNAS will have a complete control with my SATAs.
Thank you
I’m having a similar problem, but I’m using an ACASIS 5-bay RAID 0 with two 14TB Seagate IronWolf HDDs connected via USB to a miniPC with an i5 processor, 8GB of RAM, and 256GB of storage, running TrueNAS-SCALE-25.10.0.1.
Could you help me with this?
Hard Drive IronWolf 14 TB (A)
CrystalDiskInfo 9.7.2 x64
Firmware: SN03
Serial Number: ZTM0D50D
Interface: USB (Serial ATA)
Rotation Rate: 7200 RPM
Transfer Mode: SATA/300 | SATA/600
Number of Times Connected: 4 times
Number of Hours Connected: 2 hours
Standard: ACS-4
Supported Features: S.M.A.R.T., NCQ, Streaming, GPL
Hard Drive IronWolf 14 TB Hard Drive (B)
CrystalDiskInfo 9.7.2 x64
Firmware: 1000
Serial Number: ZTM0D5LP
Interface: USB (Serial ATA)
Rotation Rate: 7200 RPM
Transfer Mode: SATA/300
Number of Times Connected: 4 times
Number of Hours Connected: 2 hours
Standard: ATA/ATAPI - 7
Supported Features: S.M.A.R.T., APM
Thank you in advance!
This is your problem, and there’s no solution other than using hardware that is suitable for ZFS, namely either a PC that is large enough to host drives internally, attached to motherboard SATA ports, or a proper SAS enclosure attached through external ports from a HBA. (A SATA enclosure would work, but no port multiplier in there: Proper lanes for all drives.)
You should have opened your own thread…
Just out of curiosity: you mentioned RAID 0
However, the external enclosure presents the HDDs individually, and you can read the individual drive information with CrystalDiskInfo ?
I’m having this same error attempting to add a disk as a spare. My drives are direct attached via SCSI, no external bay, no USB, and TrueNas is not virtualized. Does anyone have any ideas why this may be the case still?
I submitted a bug report, NAS-139550, but they thought it was due to my “disk shelf”. Though I did not mention any disk shelf. I wonder if they meant just the SCSI adapter? I’m using an LSI 9300-8i.
Try the following thread. Similar issues. You didn’t list detailed hardware and I can’t see what info was submitted to the Jira ticket since I don’t work for TrueNAS. Disk shelf has to be related to your chassis.
Same error with Hyper-V and Truenas 25.10.x and 26.01.x. Drives are passed, seriald are visible in menu “DISKS” but error… BUT!
With 25.04.2.6 ALL WORKED!
The coders broke something….
PS:
HW: Xeon x99 board, E5-2697v3 CPU, 128 GB of DDR4 RAM, INTEL SATA controller with AHCI mode, 6x500GB SATA drives.
Hypervisor: Windows server 2025 Datacenter, VM v.2 profile
Andrey,
See my post in another thread about this issue. Good ol - Disks have duplicate serial numbers: None - But they don't? - #20 by HKfan
The method of getting drive serial numbers was changed between 25.04 and 25.10, making it incompatible with your virtualization.
I think I ran in the same problem with PVE,
having fully virtualized TrueNAS test systems here, and since 25.10 it has started to act up.
Though I found a solution, for the test system use case, I was using virtual SCSI disks so far, but this throws a None serial now, so switched to SATA and seems to work again (only tested with a new setup, not switching SCSI connected disks to SATA)
On my old system that does not support IOMMU (groups), I resolved this issue without passing through a controller, with just disk passthrough. The solution was to add additional “serial=” to VM conf.
nano /etc/pve/qemu-server/123.conf
...
scsi1: /dev/disk/by-id/ata-STmodel_456,serial=456,backup=0,iothread=1,size=99999K
scsi2: /dev/disk/by-id/ata-STmodel_789,serial=789,backup=0,iothread=1,size=99999K
...
Then both midclt call disk.query | jq and TrueNAS web ui were happier, and I was able to create a new pool with these disks via the TrueNAS web ui (instead of just through the CLI).
1,000% best solution
Still no resolution.
It also worked with virtual disks, which is useful if you want to try TrueNAS before going bare metal.
Thanks!
Just give them a serial. So clean and easy it hurts. In the next version, PVE must assign a sequential, random or hardware-generated serial to each device, and/or a field in TrueNAS interface to enter a serial yourself, and all solved.
They have a serial.
# lsblk -o name,serial,wwn
NAME SERIAL WWN
sda 6000c29b7ba629b5b75003dd5db7db85 0x6000c29b7ba629b5b75003dd5db7db85
├─sda1 0x6000c29b7ba629b5b75003dd5db7db85
├─sda2 0x6000c29b7ba629b5b75003dd5db7db85
└─sda3 0x6000c29b7ba629b5b75003dd5db7db85
sdb 6000c29b173bad2d77098967b388da1c 0x6000c29b173bad2d77098967b388da1c
sdc 6000c29ec478c552259d7b509d1d0263 0x6000c29ec478c552259d7b509d1d0263
sdd 6000c29291de82536ac578342096fbb6 0x6000c29291de82536ac578342096fbb6
├─sdd1 0x6000c29291de82536ac578342096fbb6
├─sdd2 0x6000c29291de82536ac578342096fbb6
└─sdd3 0x6000c29291de82536ac578342096fbb6
So clean and easy it hurts that this remains unfixed. What’s the middleware looking for that it’s not finding?
Edit: Nevermind. I’ve just spotted the other thread. A Bright Spark decided to rely solely on VPD page 0x80 even though the T10 group has never required it under any revision of SPC. It’s been optional since day one.
You can lead a horse to the water but you cannot force it to drink.
Edit2: It gets worse. VMware with disk.EnableUUID = “TRUE” in the .vmx does enable a valid response to VPD 0x80:
sg_vpd -v /dev/sdb
Supported VPD pages VPD page:
inquiry cdb: [12 01 00 00 fc 00]
[PQual=0 Peripheral device type: disk]
Supported VPD pages [sv]
Unit serial number [sn] <---- This is 0x80
Device identification [di]
Block device characteristics (SBC) [bdc]
In the Linux kernel’s include/scsi/scsi_device.h the read of 0x80 is gated behind how the device reports its scsi/SPC level; VMware disks report as legacy SCSI_2 so the kernel bypasses reading 0x80 (and likely others as well).
The workaround here should be something like scsi_mod.dev_flags=VMware:Virtual Disk S:0x10000000 which triggers BLIST_TRY_VPD_PAGES (see scsi_devinfo.h) but I can’t get it to work on the kernel command line nor as a .conf in modules.d. Based on my research it might need padding to 8chars:16chars. Or quotes. Or both.
Whatever the case, success should mean the appearance of vpd_pg80 under sys/block/*/device.