Destroyed HDD with passthrough?

dromer

New Member
Jul 25, 2026
1
0
1
Hi

I just bought a Ugreen DXP 4800 Pro to run as a nas/container/vm at home. Added a 1TB NVMe SSD (for containers and vm's storage) and a single WD Red Plus 12TB HDD (only non essential data for now). I know the standard 8GB Ram is a bit too small for this, but I will add 8GB more in the next days. I also have a 2TB Sata SSD that I wil add (for Proxmox backups) after I migrated its data to the 12 TB HDD. Until Ram/storage prices come down I plan on using only Truenas (vm) and a jellyfin container. Later I will max out ram and add more HDD's and a second NVMe.

What I did was:
  • Took a copy of UGOS with clonezilla
  • Installed Proxmox VE 9 on the internal 128GB NVMe (overwriting the UGOS)
  • Installed Truenas VM
  • Passed the HDD through to Truenas using this tutorial
And here I must have done something wrong because the HDD showed up in the vm hardware list but not in the Truenas UI. It also disappeared from the node's disk's. Since then I couldn't find it anywhere with "lsblk" or in /dev

Tried another bay and everything else I could find online without success, so I completely reinstalled Proxmox and it still won't show up.

The HDD is brand new and when it first showed up it said "passed" in the S.M.A.R.T. column.

Is my drive dead?

Thanks in advance
 
Last edited:
Good news: your disk is probably not dead. The pattern you're describing — brand new HDD that passed SMART, then disappears after a passthrough attempt and doesn't come back even after reinstalling Proxmox — is a known and recurring UGreen DXP issue, not a hardware failure.

Things to try, in order:

1) Full power cycle, not just a reboot. Shut down, unplug the power cable, wait 30 seconds, plug it back in.

2) After the power cycle, before starting any VM, check from the host:

lspci -nnk | grep -iE "sata|ahci|asmedia"
lsblk
dmesg | grep -iE "ata|sata" | head -30

If lspci sees the SATA controller and lsblk shows the disk, you're back to square one — the disk is fine.

3) Try the disk in all 4 bays (one at a time) to rule out a bad bay. Even if you've already tried "another bay", try all of them.

4) If after all this lsblk still doesn't see the disk but lspci does see the controller, likely the internal SATA cable of the bay or (rarely) the disk itself. If lspci doesn't see the controller either, the passthrough attempt really did leave the chip in a bad state — that would need a BIOS flash of the UGreen as a last resort.

Going forward, for passthrough on the DXP 4800 Pro I'd suggest not using PCIe passthrough of the SATA controller. Use per-disk passthrough instead, which is much more reliable: qm set <VMID> --scsi1 /dev/disk/by-id/ata-WDC_WD120EFBX-...
You lose some ZFS features (full SMART passthrough, some optimizations) but you avoid the ASMedia controller lockup entirely. That's what most UGreen DXP + Proxmox users end up doing after hitting this once.
Report back what lspci and lsblk show after the power cycle.