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
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.
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:
Control Panel → Network & File Services → Win/Mac/NFS/WebDAV → NFS Service → confirm it’s enabled (v2 and v3 work for my current setup).
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.
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.
I’m running a TS-h973ax and have the exact same problems. It’s really crazy that companies don’t do quality testing on the most important aspects of their software before pushing it to production.
In the age of AI, this is unacceptable. Get your act together QNAP.
Update: I solved my issue. The cause looks to be file and folder metadata that needs to be refreshed.
Go to your “Shared Folders” in Settings, and it will begin reconstructing all the metadata, which will take a long time for very large folders, as it has to walk through the whole tree. Once complete, large folders that hung operate normally again.
More from QNAPS AI:
I understand — after upgrading QuTS your SMB shared folders became slow or hung, and manually refreshing each shared folder fixed them. Here’s why that likely happened and what your refresh did.
Possible causes:
SMB service or share metadata caching became inconsistent after the firmware upgrade (access-control lists, mount states, or cached attributes).
A firmware change affected SMB I/O paths or logging behavior, causing slow responses until the share metadata/state was reloaded. (Release notes have fixes for slow SMB under certain conditions.)
Background tasks (ACL application or permission indexing) may have been interrupted by the update and needed a manual trigger to resume.
Why refreshing helped:
Refreshing a shared folder in Control Panel > Privilege > Shared Folders > Shared Folder forces the NAS to re-evaluate the share’s metadata, permissions and mount state — clearing stale caches and reinitializing SMB handlers for that share.
That reinitialization allows SMB daemons to rebuild internal state, restoring normal responsiveness.
Recommended steps (non-destructive):
Ensure you have the latest QuTS build and release notes; apply any hotfixes.
In Control Panel > Network & File Services > Win/Mac/NFS, temporarily disable and re-enable SMB to force a global service reload.
Check Control Panel > System > System Logs for SMB-related warnings and look for interrupted background tasks.
If specific shares repeatedly hang, run a permission refresh on that share and verify the underlying storage pool/RAID health in Storage & Snapshots.
Verification: After steps above, access each SMB share from a Mac/Windows client and confirm normal directory listing and read/write performance. Monitor logs for recurring SMB errors.
If the problem persists for multiple shares or recurs after reboot, please open a ticket via the QNAP Service Portal so engineers can collect logs and perform deeper diagnostics.
