Suat

One thing worth deciding while you are rebuilding anyway: whether these should be system containers at all.

If an environment exists to run one service, an application container with its data on a dataset is simpler and survives platform changes better — you have just seen what happens when the management layer disappears.

System containers earn their place when you genuinely want a persistent machine you administer: several services, a package manager, state that is not one application's database. Worth sorting your environments into those two piles before recreating all of them the same way.

On how you should have known: honestly, you could not have, and that is a real complaint rather than a gap in your process.

A deprecation that appears only in a settings page is not a notification. The people who find it are the ones who happened to open that page.

What you can do to reduce the surprise:

• Read release notes for the apps you self-host, at least the headings. Most of these changes are announced there first.
• Subscribe to the project's releases on its repository, which sends you the notes without you remembering to look.
• Do not update everything automatically on a machine holding data you care about. Automatic updates are right for security patches and wrong for major versions of an application that owns your library.

And it is worth saying to the platform's maintainers that a settings-page notice is not enough. That kind of feedback is how these become real notifications.

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.

One thing worth checking early on a storage server specifically: whether the slot the card is in shares lanes with your disk controller.

On boards with limited lanes, populating a particular slot can reduce a controller to fewer lanes or disable it entirely, and the symptom is disks disappearing rather than anything to do with the GPU.

Worth reading the board manual's lane-sharing table before deciding the card is fine where it is. It is a five-minute check and the failure it prevents is a much worse evening.

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.