SMB memory/CPU crash hanya pada folder bersama terenkripsi — QuTS hero h6.0.1.3500 (regresi dari h5.x)

Inggris Umum
,
1

Model:TS-644
Firmware: QuTS hero h6.0.1.3500 (di-upgrade dari 5.x, berfungsi baik selama dua tahun sebelumnya)
Client OS: macOS Tahoe 26.5.2

Masalah: Menjelajah folder bersama terenkripsi melalui SMB menyebabkan layanan SMB pada NAS melonjak penggunaan CPU dan memori hanya dalam hitungan detik, diikuti error restart layanan SMB pada log sistem. Klien (Finder) menjadi tidak responsif atau crash selama proses ini.

Isolasi yang telah dilakukan: - Folder SMB yang tidak terenkripsi pada NAS yang sama, pool yang sama, klien yang sama — termasuk yang ukuran besar dengan jumlah file/folder banyak — dapat berjalan dengan sempurna, tanpa masalah CPU/memori. - Hanya folder bersama terenkripsi yang memicu masalah, dan masalah ini bisa direproduksi setiap kali mencoba, dalam hitungan detik saat browsing.
Mengakses folder terenkripsi yang sama secara lokal melalui File Station (web GUI) berjalan normal — masalah terbatas pada jalur akses SMB saja, bukan pada proses enkripsi/dekripsi datanya sendiri.

Sudah dicoba, tanpa pengaruh terhadap masalah: - Menonaktifkan “Percepat transfer file menggunakan kernel SMB daemon” - Menonaktifkan “Aktifkan Asynchronous I/O” - Menonaktifkan “Percepat penyalinan file kecil dalam jumlah banyak” - Dan ketiganya dimatikan secara bersamaan

Dampak: Folder bersama ini adalah use case utama untuk NAS ini dan sebelumnya berjalan lancar sebelum upgrade ke h6. Tidak ada jalur rollback yang didukung dari h6 (format ZFS pool/ACL sudah di-upgrade secara langsung), jadi ini menjadi kendala utama tanpa solusi melalui SMB. Laporan komunitas terkait (firmware & gejala sama — ledakan penggunaan memori/CPU SMB dengan klien macOS di h6): - QuTS hero h6.0 Beta – SMB memory leak / runaway RAM with macOS Tahoe (SMB service stops) (tiket Q-202601-68940) - QuTS hero h6.0.0.3500 - HUGE Memory Leak with macOS Tahoe 26.5.2

Permintaan: Mohon perlakukan ini sebagai regresi yang spesifik pada folder bersama terenkripsi via SMB saja (bukan masalah macOS/SMB secara umum), karena dapat direproduksi pada pengujian isolasi yang bersih — klien identik, NAS identik, firmware identik, folder tidak terenkripsi tidak terdampak. Saya siap menyediakan log sistem, rekaman layar spike CPU/memori, atau akses SSH untuk debugging langsung jika diperlukan agar proses investigasi lebih cepat.

2

Kisah yang sama seperti yang lain—upgrade h6, satu share SMB tertentu di macOS (punyaku terenkripsi, tapi berdasarkan laporan lain sepertinya tidak hanya lokasi enkripsi tunggal) secara konsisten membuat CPU/RAM melonjak dalam hitungan detik saat browsing dan memaksa restart layanan SMB. Sudah mencoba menonaktifkan kernel-mode SMB daemon, async I/O, dan akselerasi file kecil — tidak ada yang menyelesaikan masalahnya.

Solusi sementara yang saat ini saya gunakan sampai masalah ini diperbaiki:

NFS adalah layanan terpisah sepenuhnya dari SMB di QuTS hero, jadi solusi ini menghindari apapun yang rusak di jalur SMB. Langkah-langkahnya:

  1. Control Panel → Network & File Services → Win/Mac/NFS/WebDAV → NFS Service → pastikan aktif (v2 dan v3 berfungsi untuk setup saya).
  2. Control Panel → Privilege → Shared Folders → [share Anda] → Edit Shared Folder Permission → NFS host access → cek Access right, tambahkan IP Mac Anda (atau subnet), atur squash ke “no users” (no_root_squash), permission sesuai kebutuhan Anda.
  3. Di Mac: Finder → Cmd+K → nfs://<nas-ip>/yourshare → Connect.

Tidak perlu terminal, mount-nya seperti network drive biasa. Ini bukan solusi permanen (QNAP tetap harus menyelesaikan regresi SMB yang sebenarnya), tapi di sistem saya, ini sangat stabil dibandingkan SMB yang jadi tidak bisa dipakai. Layak dicoba kalau Anda masih butuh akses hari ini ketimbang menunggu tiket diperbaiki.

3

Terima kasih atas laporannya! Saya akan meneruskan ini ke tim internal kami untuk verifikasi. Terima kasih!