Destroyed HDD with passthrough?

D

dromer

New Member
Jul 25, 2026
4
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.
 
Thanks for your reply!

Unplugging the power cable didn't help. I also tried all bays. Yesterday I restored to UGOS to check with another OS. Nothing worked.

The output of your commands above:

Code: 
root@dxp4800pro:~# lspci -nnk | grep -iE "sata|ahci|asmedia"
05:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1164 Serial ATA AHCI Controller [1b21:1164] (rev 02)
        Subsystem: ASMedia Technology Inc. Device [1b21:2116]
        Kernel driver in use: ahci
        Kernel modules: ahci
root@dxp4800pro:~# lsblk
NAME               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme1n1            259:0    0 119.2G  0 disk
├─nvme1n1p1        259:1    0  1007K  0 part
├─nvme1n1p2        259:2    0     1G  0 part /boot/efi
└─nvme1n1p3        259:3    0   118G  0 part
  ├─pve-swap       252:0    0   7.5G  0 lvm  [SWAP]
  ├─pve-root       252:1    0  39.6G  0 lvm  /
  ├─pve-data_tmeta 252:2    0     1G  0 lvm 
  │ └─pve-data     252:4    0  54.2G  0 lvm 
  └─pve-data_tdata 252:3    0  54.2G  0 lvm 
    └─pve-data     252:4    0  54.2G  0 lvm 
nvme0n1            259:4    0 931.5G  0 disk
├─nvme0n1p1        259:5    0  15.3G  0 part
└─nvme0n1p2        259:6    0 916.3G  0 part
root@dxp4800pro:~# dmesg | grep -iE "ata|sata" | head -30
[    0.000000] BIOS-e820: [mem 0x00000000743b7000-0x00000000744b2fff]  ACPI data
[    0.010316] NODE_DATA(0) allocated [mem 0x27fbd5280-0x27fbfffff]
[    0.021233] printk: log buffer data + meta data: 262144 + 1114112 = 1376256 bytes
[    0.063231] Register File Data Sampling: Mitigation: Clear Register File
[    0.084115] Memory: 6424788K/8141140K available (22410K kernel code, 4064K rwdata, 16156K rodata, 5092K init, 4896K bss, 1696068K reserved, 0K cma-reserved)
[    0.313245] libata version 3.00 loaded.
[    0.719090] Write protecting the kernel read-only data: 38912k
[    0.719391] Freeing unused kernel image (text/rodata gap) memory: 116K
[    0.719568] Freeing unused kernel image (rodata/data gap) memory: 228K
[    0.841759] ahci 0000:05:00.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
[    0.843166] ata1: SATA max UDMA/133 abar m8192@0x80c80000 port 0x80c80100 irq 128 lpm-pol 1 ext
[    0.843169] ata2: SATA max UDMA/133 abar m8192@0x80c80000 port 0x80c80180 irq 128 lpm-pol 1 ext
[    0.843171] ata3: SATA max UDMA/133 abar m8192@0x80c80000 port 0x80c80200 irq 128 lpm-pol 1 ext
[    0.843173] ata4: SATA max UDMA/133 abar m8192@0x80c80000 port 0x80c80280 irq 128 lpm-pol 1 ext
[    1.152163] ata1: SATA link down (SStatus 0 SControl 300)
[    1.472143] ata2: SATA link down (SStatus 0 SControl 300)
[    1.792921] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.793550] ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[    7.504927] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    7.505567] ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[    7.505573] ata3: limiting SATA link speed to 3.0 Gbps
[   13.136945] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 320)
[   13.137572] ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[   18.768968] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 320)
[   19.088219] ata4: SATA link down (SStatus 0 SControl 300)
[   19.999769] EXT4-fs (dm-1): mounted filesystem b93dcb18-9c43-4e7d-af8c-fa062fdff0cf ro with ordered data mode. Quota mode: none.
[   20.262906] systemd[1]: systemd-hwdb-update.service - Rebuild Hardware Database skipped, no trigger condition checks were met.
[   21.843238] nvme nvme0: using unchecked data buffer
 
Last edited:
Update on the diagnosis, and I owe you an apology — my "probably not dead" call was wrong. Looking at the dmesg output, the disk itself is the problem, not the controller or Proxmox.

The key lines:

ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)

Translation: the physical SATA link is working fine (the controller and the disk are electrically connected and negotiating properly at 6 Gbps). But the very first command the kernel sends after link up — IDENTIFY DEVICE, which is "hi, tell me who you are and your capacity" — is failing. Then INIT_DEV_PARAMS also fails. The kernel tries falling back to 3.0 Gbps, retries multiple times, still fails.

That's not a controller problem. The ASMedia is doing its job, it sees the drive, it can talk to it electrically. It's the drive itself that's not responding to standard SATA commands.

Two possibilities:

1) The WD Red is dead. DOA drives happen more often than people think — the "SMART passed" you saw on first boot doesn't rule this out, because SMART reflects state before a failure, and mechanical/firmware failures can happen at any moment.

2) Firmware got corrupted into a non-recoverable state. Rare but real, WD Red Plus specifically has had firmware quirks over the years.

To confirm before you RMA it, test the disk on any other system — a desktop PC's SATA port, a USB-SATA dock, anything. If it fails to identify there too, it's the disk. If it shows up fine elsewhere, then something specific to the UGreen backplane on that specific bay is at fault (unlikely since you tried all bays, but worth confirming).

If you don't have anything else to test on, contact WD support directly with the "failed to IDENTIFY (INIT_DEV_PARAMS failed)" error — that's a clear enough signature that they should honor the RMA on a brand new drive without argument.
 
  • Like
Reactions: Onslow and dromer
It seems like a DOA. Didn't work on an external dock and I found an old drive that did show up in truenas. I will return it. Thanks for your help!
 
You must log in or register to reply here.
Top Bottom
Back