Fixing a UGREEN 30353 USB-SATA Adapter That Detects a 6TB HDD as Only 1.6TB

How reflashing the Innostor IS611 bridge (firmware 0923 → 0937 plus fresh settings) restored full capacity detection, and what the logs revealed about the cause.

The problem

I wanted to wipe a 6TB Western Digital Red HDD (WD60EFAX) using ShredOS and a UGREEN 30353 USB 3.0-to-SATA/IDE adapter.

But something was wrong.

Instead of the expected 6TB, the drive appeared as approximately 1.6TB.

At first, I suspected a partition table issue or a limitation in ShredOS. However, Windows reported the same incorrect capacity.

That suggested the problem was happening below the operating system, most likely inside the USB-to-SATA bridge.

The hardware

Investigating the USB controller

Using Linux, I identified the USB device:

lsusb

The relevant USB ID was:

1f75:0611

This identifies an Innostor IS611 USB storage bridge.

I also inspected the USB device descriptor:

lsusb -v -d 1f75:0611

The controller reported:

bcdDevice 0.06
iSerial   20170420

The bcdDevice value is a USB descriptor version, not necessarily the actual firmware revision.

The iSerial is not a real serial number either. It is the date on which the chip was last programmed (the Innostor tool can generate the serial as YYYYMMDD). Keep that in mind; it becomes useful later.

To find the firmware revision, I needed the manufacturer's production tool.

What the kernel saw

The ShredOS kernel log (dmesg) showed more than just a wrong size:

scsi 3:0:0:0: Direct-Access     WDC WD60 EFAX-68SHWN0          PQ: 0 ANSI: 0
sd 3:0:0:0: [sda] 391388822 4096-byte logical blocks: (1.60 TB/1.46 TiB)
sd 3:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
sd 3:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb
sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
critical target error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Buffer I/O error on dev sda, logical block 0, async page read
 sda: unable to read partition table

Two things stand out:

1. The bridge presented the drive with 4096-byte logical sectors, although the WD60EFAX uses 512-byte logical sectors (4K physical, "512e"). The bridge was emulating 4K sectors.
2. Even reading sector 0 failed. The adapter was not just showing the wrong size. In this state it was unusable.

This matters for disk wiping: had a wipe tool written to this device anyway, it would at best have overwritten the first 1.6TB and left the rest of the disk untouched.

Why 1.6TB was suspicious

The unusual capacity was an important clue.

A 6TB disk has more 512-byte sectors than a 32-bit unsigned integer can hold. If a bridge truncates the sector count to 32 bits, the reported capacity is the remainder.

Using the drive's exact sector count instead of the nominal "6TB" turns the hypothesis into a precise match:

sectors = 11_721_045_168        # WD60EFAX LBA count (512-byte sectors)
truncated = sectors % 2**32      # 3_131_110_576

print(truncated * 512)           # 1_603_128_614_912 bytes -> "1.60 TB"
print(truncated * 512 // 4096)   # 391_388_822 -> the exact 4K block count in dmesg

The kernel's 391388822 4096-byte logical blocks matches this calculation to the block. The bridge truncated the 512-byte sector count to 32 bits before converting it into 4K blocks.

That is ironic, because 4K sector emulation is the classic trick that lets old bridges address disks beyond 2.2TB with 32-bit LBAs: 11,721,045,168 / 8 = 1,465,130,646 4K blocks fits easily into 32 bits. This firmware and configuration simply did the steps in the wrong order.

Finding the Innostor firmware tool

I found the following third-party package:

Innostor IS611 MPTool v1.0.3

https://flashboot.ru/files/file/654/

The package included a firmware image named:

611ExFW_09_37.BIN

Warning: This is not an official UGREEN firmware release. Flashing firmware from third-party sources can permanently disable your adapter. I cannot guarantee that the same firmware is compatible with other hardware revisions. The tool also requires administrator rights. Run it on a machine you don't mind exposing to a binary of unknown origin.

Reading the installed firmware

After connecting the adapter to Windows and launching the MPTool, it detected the IS611 controller.

The tool displayed:

Chip Value:
Firmware: 0923

Update Value:
Firmware: 0937

This confirmed that the adapter was running firmware 0923 and that the tool was configured to install 0937.

The firmware version was read directly from the controller, rather than inferred from its USB descriptor.

Updating the firmware and the settings

I disconnected the hard drive from the adapter before flashing.

The MPTool configuration was:

These are the settings used in my successful test, not universal recommendations. In particular, the SPI flash size must match the actual hardware.

Note the Setup Type: "Update Setting & FW" writes not only the firmware but also the bridge's configuration block, taken from the tool's profile (Profile/IS611.ini). Among other things, that profile contains:

4k_sector=0         ; 4K sector emulation off
Use_Vendor_Name=1   ; report "Innostor Ext. HDD" instead of the drive model
SATA1.5G=0          ; don't force SATA 1.5 Gb/s

More options (4K sector mode, SATA 1.5G, hot plug, motor sleep and others) are hidden behind an "Advanced Setting" dialog that asks for a password. The password ships in plain text in the tool's Other.ini.

The firmware update completed with:

PASS
Chip Done

After disconnecting and reconnecting the adapter, I scanned it again.

The tool now reported:

Chip Value:
Firmware: 0937

The USB descriptor confirmed the reflash, too: iSerial changed from 20170420 to 20261106, the day I flashed it.

The result: Full 6TB capacity!

I reconnected the WD60EFAX and ran the following command in Windows PowerShell:

Get-Disk | Format-Table Number,FriendlyName,Size,BusType

The result:

Number FriendlyName                 Size BusType
------ ------------                 ---- -------
0      WD Blue SN570 250GB  250059350016 NVMe
1      Innostor Ext. HDD   6001175126016 USB

6,001,175,126,016 bytes!

I then booted ShredOS natively again. The kernel now saw:

scsi 3:0:0:0: Direct-Access     Innostor Ext. HDD              PQ: 0 ANSI: 0
sd 3:0:0:0: [sda] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
 sda: sda1

Full capacity, native 512-byte sectors, and the partition table was readable again.

Firmware or settings?

Since both the firmware and the settings were rewritten in one go, I can't say for sure which change fixed the problem. The most plausible explanation is that the old configuration had 4K sector emulation enabled and firmware 0923 implemented it incorrectly. Whether firmware 0937 fixes that bug, or whether simply disabling 4K emulation avoided it, would need a second experiment: flashing 0937 with 4k_sector=1. Since the adapter now works, I'm not going to risk it.

The wipe itself

With the fixed adapter, nwipe (ShredOS v2025.11, nwipe 0.43.1) ran for almost four days:

• Method PRNG Stream (SplitMix64). I aborted it after 6 complete rounds, each covering all 6,001,175,126,016 bytes.
• 0 errors: write, sync, verification and retries.
• The SMART reallocated sector count stayed at 0, so no old data was left behind in remapped sectors.

Six clean full-disk passes also show something the capacity report alone can't: the region above the old 1.6TB limit was really addressable and writable.

Important limitations

A correct capacity report does not by itself prove that every sector can be read and written reliably. The full wipe above does.

I have not established that firmware 0937 fixes every large-drive compatibility issue, nor that it is safe for all UGREEN 30353 hardware revisions.

Things I observed with this adapter even after the fix:

• Model name hidden: With Use_Vendor_Name=1, tools show "Innostor Ext. HDD" instead of the drive model, including the nwipe PDF report. Serial number and SMART data still come through correctly via SAT pass-through (smartctl -d sat).
• Flaky ATA pass-through: nwipe reported HPA/DCO as "Unknown", the kernel logged usb 2-1: reset SuperSpeed USB device while nwipe probed for HPA/DCO, and smartctl reported SMART STATUS command failed: Connection timed out. None of this happened during the actual writes. If you need ATA Secure Erase or another drive-level sanitization feature, use a direct SATA connection.
• Slow: The adapter runs plain USB mass storage (usb-storage, no UASP), and the SATA link negotiated only 1.5 Gb/s, although the "SATA 1.5G" option was off. Throughput was about 111 MB/s, so one pass over 6TB took about 15 hours. The disk itself manages about 150 MB/s on average. For large disks, a UASP bridge (e.g. ASMedia ASM1153E or ASM235CM, or JMicron JMS578) is the better tool.

For secure data erasure, use an appropriate method and verify the completed operation.

Conclusion

This was a surprisingly satisfying hardware debugging exercise.

The initial symptom looked like a defective disk or a storage-tool limitation. Instead, the bridge had truncated the sector count to 32 bits while emulating 4K sectors, and it couldn't even read sector 0. Reflashing the Innostor IS611 with firmware 0937 and fresh settings fixed it.

The key lessons:

• When a large SATA disk reports a strangely specific smaller capacity through USB, compute sectors % 2**32 with the drive's real LBA count. If it matches, the bridge is the problem, not the disk.
• Check the logical sector size in dmesg. Unexpected 4096-byte blocks point to 4K emulation in the bridge.
• An adapter that shows the wrong capacity is dangerous for wiping: it may silently leave most of the disk untouched.

Hardware: UGREEN 30353 + WD60EFAX 6TB
Controller: Innostor IS611 (1F75:0611)
Firmware: 0923 → 0937 (with settings rewritten, 4K emulation off)
Result: 1.60TB (4K blocks, unreadable) → 6.00TB (512-byte sectors), 6 clean wipe passes

If you've encountered the same issue with an Innostor-based adapter, I'd be interested to hear which firmware revision, settings and drive capacity you're using. If you've tried 0937 with 4K emulation enabled, I'd especially like to know the result.