Minisforum N5 Pro - JMB585 Controller

[rayven1lk]

Hi guys, I came across your review of the Minisforum N5 Pro and was so excited to research this NAS which is more of an "All-in-one" server. Unfortunately, while I was looking into it, it seems there is a potentially serious reliability issue with the N5 Pro related to its onboard SATA controller (JMB585). Multiple users have reported that under sustained write or mixed I/O load, the controller appears to reset or reinitialize mid-operation. When this happens, ZFS ends up receiving corrupted data before checksums are written, which results in silent data corruption on the pool. Once ZFS later reads the data back, the checksum mismatch is detected — but at that point the corruption has already been committed.

Unfortunately, I cannot share links here, but if you lookup:
1) (Silent) Data Corruption on N5 Pro NAS: r/MINISFORUM
2) AOOSTAR WTR Max vs Minisforum N5 Pro: Level1techs forum

These threads describe the issue and show some logs that cover the issue. The Level1Techs thread has a few posts where the controller is described as unreliable under heavy I/O loads. What’s concerning is that this doesn’t appear to be a one-off drive failure — symptoms are consistent with controller-level resets, hitting all drives at once.
I’m not sure how widespread the problem is, but Minisforum hasn’t issued an official response yet. That uncertainty makes it hard to trust the N5 Pro as a primary NAS, which is a shame considering how strong the rest of the hardware is and how well it was positioned as an “all-in-one” homelab box.

Not sure if you're already aware of this issue, but would love it if you could raise this with Minisforum and see if they can acknowledge the issue or outline any planned fixes — firmware, board revision, etc. It would help a lot of people (including myself) make informed decisions. Thanks.

TL;DR:

N5 Pro’s JMB585 SATA controller may reset under load → corrupts in-flight writes → ZFS only catches it after corruption is written. Until Minisforum responds, data-integrity-focused users are hesitant to trust it as a NAS.

[ed]

The JMB585 itself is normally a stable controller
It is widely used in smaller NAS and DIY builds. Under normal conditions it handles SATA traffic well, and many systems run it for years without problems. The trouble begins when:

• all 5 ports are saturated at once
• heavy mixed read and write workloads are running
• the firmware or power delivery is marginal

When that happens, some units appear to trigger a controller reset. That instantly drops all drives for a moment.

What that means for ZFS
ZFS expects the underlying hardware to be stable. If the controller resets mid write, ZFS can write bad data to disk before it has a chance to generate checksums. When ZFS later verifies the checksum, it sees corruption — but at that point the corrupted data is already committed.

This is not a ZFS bug. It is a hardware level issue.

Is it widespread
Hard to say yet. There are multiple independent reports, and they are all describing the same symptoms, which makes this worth attention. But not every user is seeing it, which suggests a batch, firmware, or board level variance.

If data integrity is your top priority
At the moment the safer options are:

• Aoostar WTR Max
• Topton / Hunsn variants with ASM1166
• Any board with an onboard Intel, AMD, or LSI based SATA solution

These have not shown the same reset behaviour.

Thanks again for flagging this.