SMB memory/CPU crash on encrypted shared folder only — QuTS hero h6.0.1.3500 (regression from h5.x)

English General
,
1

Model:TS-644
Firmware: QuTS hero h6.0.1.3500 (upgraded from 5.x, working fine for two years prior)
Client OS: macOS Tahoe 26.5.2

Issue: Browsing an encrypted shared folder over SMB causes the NAS SMB service to spike CPU and memory within seconds, followed by SMB service restart errors in the system log. The client (Finder) hangs/crashes during this.

Isolation performed: - Unencrypted SMB shares on the same NAS, same pool, same client — including large ones with heavy file/folder counts — work perfectly, no CPU/memory issue. - Only the encrypted shared folder triggers the problem, and it triggers reliably, every time, within seconds of browsing.
Accessing the same encrypted folder locally via File Station (web GUI) works fine — issue is specific to the SMB access path, not the encryption/decryption of the data itself.

Already tried, no effect on the issue: - Disabling “Accelerate file transfer using kernel SMB daemon” - Disabling “Enable Asynchronous I/O” - Disabling “Accelerate copying large number of small files” - And all three disabled simultaneously

Impact: This share was the primary use case for this NAS and worked without issue for years prior to the h6 upgrade. There is no supported rollback path from h6 (ZFS pool/ACL format is upgraded in place), so this is currently a hard blocker with no workaround via SMB. Related community reports (same firmware line, same symptom signature — SMB memory/CPU blowup with macOS clients on h6): - QuTS hero h6.0 Beta – SMB memory leak / runaway RAM with macOS Tahoe (SMB service stops) (ticket Q-202601-68940) - QuTS hero h6.0.0.3500 - HUGE Memory Leak with macOS Tahoe 26.5.2

Request: Please treat this as a regression tied to the encrypted-shared-folder SMB path specifically (not a general macOS/SMB issue), since it reproduces on a clean isolation test — identical client, identical NAS, identical firmware, unencrypted shares unaffected. Happy to provide system logs, a screen recording of the CPU/memory spike, or SSH access for live debugging if that speeds things up.

2

Same story as everyone else - h6 upgrade, one specific SMB share on macOS (mine’s an encrypted share, but going by other reports it may not even be single encryption location specific) reliably spikes CPU/RAM within seconds of browsing and forces an SMB service restart. Tried disabling kernel-mode SMB daemon, async I/O, and the small-files acceleration toggle — none of it touched the issue.

My current, tested, workaround until this is resolved:

NFS is a completely separate service from SMB on QuTS hero, so it sidesteps whatever’s broken in the SMB path entirely. Steps:

  1. Control Panel → Network & File Services → Win/Mac/NFS/WebDAV → NFS Service → confirm it’s enabled (v2 and v3 work for my current setup).
  2. Control Panel → Privilege → Shared Folders → [your share] → Edit Shared Folder Permission → NFS host access → check Access right, Add your Mac’s IP (or subnet), set squash to “no users” (no_root_squash), permissions as you need.
  3. On the Mac: Finder → Cmd+K → nfs://<nas-ip>/yourshare → Connect.

No terminal required, mounts like a normal network drive. It’s not a fix (QNAP still needs to sort out the actual SMB regression), but it’s been fully stable for me where SMB became unusable. Worth trying if you’re stuck and need access today rather than waiting on a ticket.

3

Thanks for the report! I’ll forward this to our internal team for verification. Thanks!