Trying to create a pool, the system stops with an error saying disks have duplicate serial numbers, and the value it shows is empty or identical across several drives.
The drives are physically different units. Some are in an external enclosure connected over USB.
Why does this matter to the storage system, and what are my options — is this a fault with the drives, or with how they are connected?
Worth confirming what the system is seeing before buying anything, because it takes a minute and it tells you whether the enclosure is the culprit:
lsblk -o NAME,SERIAL,WWN,TRAN,SIZE
Look at the transport column and the serial. If everything on usb shows an empty or identical serial while anything on sata shows a real one, you have your answer directly.
The WWN column is worth noting too — it is another stable identifier, and a bridge that drops the serial sometimes drops that as well. A drive with neither is invisible to any sane identity scheme.
It matters because the serial number is how the system identifies a disk across reboots, and identity is the foundation of everything a redundant pool does.
Device names are not stable — the disk that is sda today can be sdc tomorrow depending on enumeration order. So a storage system tracks members by a stable identifier, and the serial is it. Two disks reporting the same identifier means the system cannot tell them apart, which means it cannot know which one failed, which one to resilver, or which one it is writing to.
Refusing to build the pool is the correct behaviour. A pool built on ambiguous identity is one that silently does the wrong thing during a failure, which is precisely when you need it to do the right one.
And the cause is almost certainly the enclosure rather than the drives.
One broader point for anybody assembling storage from what is to hand: this error is doing you a favour by appearing now.
The alternative version of this story is a pool that builds fine, runs for a year, and then behaves unpredictably during a disk replacement because the system cannot reliably tell two members apart. That failure happens at the worst possible moment and is much harder to reason about.
A storage system that refuses to start on ambiguous hardware is one that will also refuse to guess later.
@storage_suat · 6d ago
The reason is the bridge chip. A USB enclosure translates between USB and the disk's native protocol, and a cheap bridge often does not pass the disk's real identity through — it reports its own, or an empty string, or the same value for every drive behind it.
So the drives are fine and the adapter is lying.
What to do:
Connect them directly. A native port on the board, or a proper host bus adapter. This is the answer, and it is why USB enclosures are advised against for storage arrays generally — the identity problem is only the first symptom. They also drop connections under load, hide device errors, and do not pass through the drive's health data.
If an enclosure is unavoidable, some bridges support a mode that passes the underlying disk through properly. It varies by chipset and is worth checking, and it is a workaround rather than a fix.
What I would not do is force the pool past the check. The identity problem does not go away, it waits for a disk to fail.
Reply
Report