TerraMaster Forum

I need help with a D2-320 that appears to be aggressively power-cycling / parking disks.

Hardware

- TerraMaster D2-320
- 2 x Seagate ST16000VN001-2YU101 16TB
- drives used as separate disks, not a RAID volume
- MEDIA1 = active media disk
- MEDIA2 = weekly backup disk, unmounted most of the time

Host setup

- primarily used on macOS
- independent mode (NO RAID, NO JBOD)
- filesystems are APFS
- MEDIA1 mounted under /Users/<>/Media/MEDIA1
- MEDIA2 often left unmounted
- for more reliable SMART passthrough, I temporarily attached the enclosure to a VMware Fusion Ubuntu VM and ran smartctl there
- on macOS, SMART passthrough is inconsistent: sometimes I can read some SMART data with DriveDx and sometimes with smartmontools CLI, but it is not
reliable through the USB bridge

Observed problem

- the enclosure repeatedly does audible spin-up -> stop -> spin-up cycles
- this happens even when services are not actively using the disk (stopped services)
- one of the strongest clues is that the backup disk (MEDIA2) shows almost the same cycle pattern even though it was unmounted around 90% of the time

SMART health

both drives report PASSED, with no reallocated, pending, offline uncorrectable, or CRC errors, and short self-tests complete successfully
So the drives do not look like bad media. The problem looks more like enclosure / bridge / power-management behavior.

Cycle counts from SMART

For MEDIA1 (/dev/sda in Fusion VM):

- Power_On_Hours = 1614
- Start_Stop_Count = 11721
- Power_Cycle_Count = 11743
- Load_Cycle_Count = 21296

For MEDIA2 (/dev/sdb in Fusion VM):

- Power_On_Hours = 1564
- Start_Stop_Count = 11599
- Power_Cycle_Count = 11627
- Load_Cycle_Count = 16294

Those counts seem far too high for only a couple of months of use.

Why I do not think this is normal idle sleep only

- there was previously a 10 minute sleep timeout in the environment
- but the numbers are still too high to be explained cleanly by that alone
- MEDIA1 also had at least about a week of continuous media playback time, so it was not even idle enough for a simple 10-minute timeout pattern to
explain all cycles
- MEDIA2 being mostly unmounted but still having nearly the same cycle counts makes me suspect enclosure-level or bridge-level behavior rather than normal
filesystem access

macOS checks already done

- set pmset disk sleep off:

sudo pmset -a disksleep 0

- current macOS settings also showed:
- sleep 0
- standby 0
- so macOS idle disk sleep and normal system sleep are effectively disabled right now

Even after that, the issue still appears active.

SMART/self-test observations

- short tests pass
- one old extended self-test entry shows:
- Interrupted (host reset) at lifetime hour 0
- SATA PHY log showed very low reset-related counts, not enough by themselves to explain the large cycle totals
- no obvious media-failure indicators

USB / bridge / logging observations

- on macOS, Disk Arbitration logs were noisy and not very conclusive
- I did not get clean proof of repeated detach/reattach from macOS logs alone
- however, the audible repeated spin-up/stop behavior is real
- recent Fusion SMART stats still showed counters increasing over a short interval, which suggests the cycling is still active

Support experience
This is part of why I am posting here.

TerraMaster support has not given me a clean, confidence-inspiring answer:

- the firmware install link they sent is a forum post:
- viewtopic.php?t=7111
- that forum post is for D4-320/D6-320, not D2-320
- separately, support sent a D2-320 firmware/tool package through Google Drive
- there is no proper D2-320 firmware page, checksum, or clear model-specific documentation trail
- their email also contradicts itself: it tells me to download the tool/firmware, then immediately warns not to download it if the link is not for the D2-
320 because incompatible firmware could crash the system during upgrade

At this point I cannot tell what is actually official and safe to flash for the D2-320.

What I need help with

- Has anyone else with a D2-320 seen aggressive disk power-cycling / parking like this?
- Is there confirmed D2-320 firmware that fixes this?
- Has anyone used the support-provided firmware successfully on this exact model?
- Is this a known USB bridge / enclosure behavior on macOS?
- Did moving the same drives to a different enclosure stop the issue?

SMART excerpts.

If TerraMaster rejects a return or replacement, Amazon told me they may still be able to help even though the normal return window has passed, especially
if this ends up being treated as an incompatibility or product behavior issue rather than normal use.
I am having a hard time getting a resolution on this

The message in the email is simply to allow some customers to confirm one last time that their model is indeed D2-320 before installing the firmware. You can update the firmware first.

Additionally, have you tried changing the USB cable and port, or observing whether the same phenomenon still occurs without connecting to a virtual machine?

I can’t update the firmware because the link in the support email points to firmware for a different model, that too in a forum thread and windows only, when mac support is advertised for this DAS. But I can use a VMWare and update the firmware.
Please send the correct firmware for my exact model, and I will update it.

I found the spin cycles are due to the NAS drive firmware’s APM behavior - SeaTools can change this behavior.
SO ONE PART SOLVED.
But random re-enumeration is still an issue. I am also seeing 261 hardware resets SEE above S.M.A.R.T test excerpt.

See DAS resets
dmsg -Tw
issue here:

[Tue Apr 21 15:11:32 2026] scsi host30: uas_eh_device_reset_handler start
[Tue Apr 21 15:11:32 2026] usb 3-1: reset SuperSpeed Plus Gen 2x1 USB device number 6 using xhci_hcd
[Tue Apr 21 15:11:32 2026] scsi host30: uas_eh_device_reset_handler success

Options
1. you cant send me the firmware update.
2. Please approve a return
3. resolve my issue as non-returnable - I will contact Amazon for exceptions

more info:
- Using same cable that came with the box. same issue across all cables brand new high end Power Delivery thunderbolt cable- ALL Same.
The issue is on MacOS, NOT on VMs

Any kind of firmware like this one at least delivered without with windows compatibility or even forum post which is for this model D2-320 is welcome
example: https://eshop.macsales.com/manuals/owc- ... hYuWXFsYIR

Thank you for the additional information. Please reply to the private message with the email address you used to communicate with support, and we will verify it.

Sent my email ID via direct message.
Awaiting response.

More info:
I found aggressive sleep behavior triggered by DAS when the disk firmware is set to sleep only after 30 minutes (Idle_B timer on Seagate HDD).

Mac power is set to disk sleep 0 — meaning don’t spin down disks — and Power Nap is disabled.

macOS also wakes the disk up, and there is always chatter and probing from macOS services, even when Spotlight and APFS snapshots are turned off. So the disk should stay up with the fan running. Instead, this DAS is biased to spin down at the nearest idle opportunity, lower fan speed, reduce power usage, and project a low-noise consumer appliance — at the cost of drive longevity.

This result in the drives aggressively park heads and sleep, drawing down from the 600,000-cycle quota on a typical NAS HDD. This is unnecessary when thermals are easy to manage in an air-conditioned room with an 80mm fan.
As an engineer with two decades of experience, in my opinion this is not a great firmware design choice. If thermals and noise were the reason, the consumer could have been given a manual power management toggle at the back of the unit. I sincerely ask TerraMaster’s product designers to consider this and fine-tune the chipset firmware accordingly.

This is quite the opposite of what is advertised in the product marketing documentation — which states that the drive follows macOS sleep — yet here macOS is not sleeping but the disks are. I also don’t want to keep writing to the disk to keep it alive using a service or app like Amphetamine. I want the DAS to sleep on genuine disk inactivity of 30 minutes, not aggressively triggered by the DAS itself.

I would seriously consider returning this unit if this cannot be patched.​​​​​​​​​​​​​​​​

We are very sorry for the inconvenience caused. Thank you for the additional information. We have checked the email and our engineer has replied via email. Please confirm whether you have received the technical support email.

No email response yet.
Kindly keep this more transparent, if update is possible others could benefit.

We have tested and verified the D2-320 and multiple similar devices on the market. After setting the sleep timer for external enclosures in macOS, third-party external drive enclosures fail to enter automatic sleep as scheduled.
In contrast, the D2-320 synchronizes its sleep status with the macOS system. To prevent frequent sleep cycles of the D2-320, it is recommended to appropriately adjust the computer’s sleep delay time to reduce the device’s sleep frequency.
The above are our actual test and verification results for this round. We welcome everyone to exchange and discuss together.

Please go through the details again. The behavior you tested is different from the issue I described.

I had already set macOS power management so that the host itself should NOT be going to sleep:

* disksleep = 0
* Power Nap is off

So I am not expecting the Mac to sleep, and in turn I would not expect the TDAS to sleep either, especially while services need to often access disks (even though not sustained read/writes).

What I am observing instead is that the TDAS appears to follow disk inactivity too aggressively, likely tracking the HDDs’ own power-management behavior rather than actual host usage. In other words, it seems to be reacting to the disks as soon as there is no sustained read/write activity, even when the host and services are still active.

It also appears to do this incorrectly. For example, I changed the Seagate drive firmware power-management settings using SeaChest CLI so that the drive’s Idle_B timer is now 30 minutes in firmware and 45 min for standby_z time, not the default short timer. Even after that, the TDAS still goes to sleep the minute whenever there is no prolonged read/write happening.

So the issue is not simply macOS sleep settings. The problem is that the enclosure seems to be independently entering sleep based on short storage inactivity at SATA bridge level, instead of respecting the active host environment (the MacOs) and the drive-level timer changes already applied.

I do not want to make this a brand comparison, but I do have another enclosure from a different vendor running side by side with similar Seagate disks under exact host conditions, and the difference in behavior is obvious.

Your enclosure (TDAS) appears to enter sleep very aggressively whenever there is a lull in sustained read or write activity. The other enclosure does not; it respects the host-side “do not sleep disks” behavior and keeps the drives available.

From a drive-behavior point of view, this matters. NAS and enterprise-class HDDs used in an always-on media/server role are not best served by frequent unnecessary park/unpark and spin-down/spin-up transitions. Those transitions increase mechanical cycle counts such as head load/unload and start/stop events. For a workload that is intended to remain online 24/7, repeated forced idle transitions are often less desirable than simply letting the drive continue spinning through ordinary short idle gaps.

So my concern is not just convenience or wake-up delay. It is that the enclosure seems to impose its own aggressive sleep policy in a way that overrides or ignores both:

* the host’s no-sleep intent, and
* the drive’s own firmware-level power settings

That can work against drive longevity and against the intended use case of NAS-class disks in a continuously available storage enclosure.

The TDAS seems tuned for aggressive consumer-style sleep, not always-on or SOHO use, and in practice it does not honor macOS power settings as its marketing suggests. That mismatch between advertised behavior and real behavior is the issue I need addressed.

Also, this is apart from the elevated SMART Hardware Reset count already accumulated over time, which suggests some of these power transitions are not ending cleanly. That further strengthens my concern about the enclosure’s sleep/wake handling.

These behavior may be acceptable to some customers, but it does not fit my use case, so I need to return the unit to you.