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
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.
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:
Control Panel → Network & File Services → Win/Mac/NFS/WebDAV → NFS Service → pastikan aktif (v2 dan v3 berfungsi untuk setup saya).
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.
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.
Saya menggunakan TS-h973ax dan mengalami masalah yang persis sama. Benar-benar gila bahwa perusahaan tidak melakukan pengujian kualitas pada aspek terpenting perangkat lunak mereka sebelum dirilis ke produksi.
Di era AI seperti sekarang, ini tidak bisa diterima. QNAP, tolong benahi dirimu.
Pembaruan: Saya sudah berhasil menyelesaikan masalah saya. Penyebabnya tampaknya adalah metadata file dan folder yang perlu diperbarui.
Buka “Shared Folders” di Settings, dan proses rekonstruksi metadata akan dimulai, yang memakan waktu lama untuk folder yang sangat besar, karena sistem harus menelusuri seluruh pohon folder. Setelah selesai, folder besar yang sebelumnya macet kini berjalan normal kembali.
Selengkapnya dari QNAPS AI:
Saya mengerti — setelah melakukan upgrade QuTS, folder SMB sharing Anda menjadi lambat atau hang, dan penyegaran manual pada setiap folder sharing bisa memperbaiki masalahnya. Berikut alasan kemungkinan terjadinya masalah serta apa yang dilakukan penyegaran.
Kemungkinan penyebab:
Cache metadata layanan SMB atau share menjadi tidak konsisten setelah update firmware (access-control list, status mount, atau atribut yang di-cache).
Perubahan firmware memengaruhi jalur I/O SMB atau perilaku logging, menyebabkan respons yang lambat hingga metadata/status share dimuat ulang. (Catatan rilis menyebutkan ada perbaikan untuk SMB lambat dalam kondisi tertentu.)
Tugas latar belakang (aplikasi ACL atau pengindeksan izin) mungkin terputus akibat update dan perlu dipicu secara manual agar berjalan kembali.
Mengapa refresh membantu:
Menyegarkan folder sharing di Control Panel > Privilege > Shared Folders > Shared Folder memaksa NAS untuk mengevaluasi ulang metadata share, izin, dan status mount — membersihkan cache yang sudah usang dan menginisialisasi ulang handler SMB untuk share tersebut.
Inisialisasi ulang memungkinkan daemon SMB untuk membangun ulang state internal, sehingga respons kembali normal.
Langkah yang disarankan (non-destruktif):
Pastikan Anda telah menggunakan build QuTS terbaru dan membaca catatan rilis; terapkan hotfix jika ada.
Di Control Panel > Network & File Services > Win/Mac/NFS, nonaktifkan dan aktifkan kembali SMB untuk memaksa reload layanan secara global.
Periksa Control Panel > System > System Logs untuk peringatan terkait SMB dan cari tugas latar belakang yang terputus.
Jika sharing tertentu terus macet, lakukan refresh izin pada share tersebut dan pastikan kesehatan storage pool/RAID dasar di Storage & Snapshots.
Verifikasi: Setelah langkah-langkah di atas, akses masing-masing share SMB dari klien Mac/Windows dan pastikan daftar direktori serta performa baca/tulis normal. Pantau log untuk kesalahan SMB yang berulang.
Jika masalah tetap terjadi pada beberapa share atau muncul kembali setelah reboot, silakan buka tiket lewat QNAP Service Portal agar engineer dapat mengumpulkan log dan melakukan diagnosis lebih lanjut.
