Apakah folder bersama `homes` bisa dienkripsi di QuTS hero?

English Penyimpanan
1

Folder bersama homes yang ditampilkan tidak memiliki opsi enkripsi di UI. Tampaknya folder ini dibuat dan dikelola secara otomatis oleh sistem ketika folder home diaktifkan, bukan melalui dialog “Buat Folder Bersama” biasa tempat kotak centang enkripsi berada.

Karena ZFS tidak dapat mengaktifkan enkripsi pada dataset yang sudah ada (zfs get menunjukkan encryption sebagai
EDIT: NO), ini tampaknya tidak bisa diperbaiki setelahnya.

Hal ini penting karena folder home di sini akan berisi dokumen pribadi yang benar-benar nyata.

Pertanyaan

  1. Apakah folder bersama homes dapat dienkripsi di QuTS hero? Apakah ketiadaan opsi ini memang batasan desain, atau saya mencari di tempat yang salah?

  2. Jika folder home dinonaktifkan lalu diaktifkan kembali, apakah dataset dasarnya dibuat ulang — dan jika iya, apakah bisa dibuat terenkripsi?

  3. Apakah ada cara resmi untuk menempatkan folder home di dalam folder bersama terenkripsi, atau untuk mengarahkannya ke dataset yang sudah saya buat terenkripsi?

  4. Jika tidak ada: apa solusi yang biasa dilakukan? Rencana saya adalah menjaga homes seminimal mungkin — hanya yang diperlukan perangkat — dan memberikan setiap pengguna folder bersama terenkripsi normal untuk dokumen mereka, yang dipetakan sebagai drive mereka. Apakah ada pola yang lebih umum dipakai?

2

Folder homes adalah fitur opsional di QuTS (dan sepertinya juga QTS). Kamu tidak harus mengaktifkannya. Mungkin ada beberapa aplikasi Linux, tetapi karena folder ini agak seperti folder “OS”, kamu sebenarnya tidak bisa (dan kemungkinan juga tidak ingin) mengenkripsinya. Lebih baik kamu memberikan folder bersama terenkripsi untuk setiap pengguna yang disimpan di tempat lain. Folder terenkripsi bisa berisiko karena jika seseorang kehilangan kunci enkripsinya, tidak ada cara untuk memulihkan data tersebut. Selain itu, backup juga tidak bisa dilakukan jika folder terenkripsi terkunci.

Kamu tidak bisa memindahkan folder “homes” beserta hierarkinya.

Sepertinya kamu tidak bisa mengenkripsi folder tertentu di QuTS. Di QuTS Hero, kamu harus membuat folder bersama dan memilih opsi enkripsi saat membuat folder bersama tersebut. Perlu diingat bahwa setiap folder bersama dianggap sebagai volume tersendiri di QuTS. Kamu kemudian harus mengatur izin pengguna untuk masing-masing volume tersebut.

3

Terima kasih atas sarannya — saya menonaktifkan home folders dan kemudian menemukan sesuatu yang patut didokumentasikan.

Ketika home folders dinonaktifkan, /share/homes tidak dihapus. Folder tersebut diarahkan ulang ke sebuah placeholder:

lrwxrwxrwx  /share/homes -> /tmp/homes/
tmpfs on /tmp type tmpfs (rw,size=128M)

Jadi /share/homes menjadi RAM disk sebesar 128 MB. /etc/passwd masih mencantumkan /share/homes/<user> sebagai direktori home, sehingga pengguna shell mendapatkan home yang ada di tmpfs. Saya memastikan hal ini dengan melakukan reboot: direktori home benar-benar terhapus. Saya sebelumnya telah menyalin folder .ssh ke sana secara manual agar akses SSH berbasis kunci tetap tersedia, dan folder itu hilang. Untungnya saya sudah memverifikasi login dengan password sebelumnya, kalau tidak saya bisa saja terkunci dari sistem.

Pertanyaan saya: jika seseorang memang sengaja tidak ingin menggunakan fitur home folders bawaan, apa cara yang didukung untuk mengatur ini? Secara spesifik:

  1. Apakah ada cara yang didukung untuk mengarahkan direktori home pengguna ke shared folder biasa, yang tetap ada setelah reboot dan update firmware? Mengedit /etc/passwd langsung terasa sia-sia karena file itu dihasilkan ulang saat boot.
  2. Apakah redirect ke tmpfs ini memang disengaja, atau hanya fallback yang tidak dirancang untuk dipakai secara permanen?
  3. Untuk pengguna SMB, adakah cara agar shared folder terpisah (misal yang terenkripsi) muncul dalam satu struktur folder, selain mapped drives atau namespace Windows DFS? Symlink tidak bisa digunakan karena restriction wide-links di Samba, jadi itu bukan opsi.

Idealnya saya ingin tata letak yang stabil dan terdokumentasi, bukan workaround yang akan rusak di update firmware berikutnya.

4

Saya rasa tidak ada cara yang didukung untuk melakukan ini, jadi saya menggunakan satu folder bersama terenkripsi untuk semua pengguna, kemudian menggunakan ACL agar pengguna tidak bisa mengakses file milik orang lain.

5

Saya tidak tahu cara untuk melakukan apa yang Anda tanyakan. Mungkin Anda bisa mengatur sesuatu di skrip boot/login, tapi saya tidak yakin. Mungkin orang lain bisa memberikan komentar.

Kenapa tidak lakukan ini saja:

  1. Biarkan folder home user tetap aktif dan seperti sekarang.
  2. Buat share terenkripsi untuk setiap user, tempat mereka menyimpan data yang memang perlu dienkripsi.

Apa alasan Anda ingin mengenkripsi SEMUA data milik pengguna di NAS?

6

Terima kasih atas pertanyaannya! Saya akan meneruskannya ke tim internal kami untuk mendiskusikan masalah yang Anda ajukan.

7

Terima kasih atas rekomendasinya: Saya akan membuat volume terenkripsi untuk para pengguna (share people) dan menggunakannya sebagai $HOME mereka. Namun, selalu ada risiko bahwa kunci dan data pribadi lainnya bisa berakhir di share homes yang default dan tidak terenkripsi. Bagi saya, itu benar-benar tidak bisa diterima.

Saya agak terkejut dengan pertanyaan mengapa semuanya harus dienkripsi sekarang—terutama direktori home. Bagaimanapun juga, di situlah kunci pribadi dan data pribadi disimpan. Saat ini saya sedang migrasi dari Synology (Synology terasa agak ketinggalan zaman dan sepertinya kurang punya ambisi pengembangan lebih lanjut, sementara QNAP tampak jauh lebih ambisius; jadi, saya tidak menyesal beralih ke QNAP). Tapi, selama bertahun-tahun saya juga mengenkripsi semuanya di NAS Synology saya. Di Windows pun sama: BitLocker mengenkripsi semua drive dan sistem file. Bagaimana kalau hard disk dicuri? Enkripsi end-to-end itu wajib. Zero Trust.

Hal yang sama berlaku untuk share public. Saya tidak bisa menghapus maupun mengenkripsi share tersebut. Meskipun namanya public, share ini hanya bisa diakses di LAN saya, bukan keluar ke dunia luar. QNAP memang seharusnya memikirkan soal ini dengan lebih serius.

8

Uh, tidak ada private key dan data “pribadi” yang disimpan di direktori home. Saya nggak tahu dari mana kamu dapat ide itu.

Ini adalah direktori home akun admin di salah satu NAS saya:

[admin@NA9D-NAS-3 ~]# pwd
/share/homes/admin
[admin@NA9D-NAS-3 ~]# ls
@Recycle@
[admin@NA9D-NAS-3 ~]# ls -la
total 65
drwxrwx--- 6 admin administrators   10 2026-08-19 22:56 ./
drwxrwxr-x 7 admin administrators   11 2026-07-22 18:03 ../
-rwxrwx--- 1 admin administrators 8983 2026-08-20 06:24 .bash_history*
drwxrwx--- 3 admin administrators    3 2025-09-04 09:23 .cache/
drwxrwx--- 2 admin administrators    4 2026-03-30 19:21 .composer/
drwxrwx--- 3 admin administrators    3 2025-12-23 20:20 .config/
drwxrwxrwx 3 admin administrators    3 2025-09-07 19:08 .Qsync/
lrwxrwxrwx 1 admin administrators   27 2026-07-31 17:19 @Recycle -> /share/homes/@Recycle/admin/
-rwxrwx--- 1 admin administrators 3886 2026-08-19 22:56 .viminfo*
-rwxrwx--- 1 admin administrators  212 2026-09-13 11:15 .wget-hsts*
[admin@NA9D-NAS-3 ~]#

Nggak ada apa pun di situ yang berupa key atau data user “pribadi”. Satu-satunya data pribadi yang mungkin user taruh di sini adalah data yang mereka anggap pribadi. Kalau mereka ingin melindunginya, mereka bisa saja mengenkripsi folder mereka sendiri.

Menurut saya kamu benar-benar terlalu memikirkan ini.

Kalau kamu punya sistem NAS multi-user yang benar-benar dilindungi dari internet (artinya: nggak diekspos), maka keamanan antar user cukup pakai password dan ACL. Satu user nggak bisa mengakses direktori home user lain tanpa ACL yang benar. Memang ada kemungkinan ada user yang coba hack jalannya ke sana, tapi biasanya orang seperti itu kemungkinan besar bakal coba melakukan hal buruk lain daripada sekadar mengakses file random milik user lain. Selain itu, kalau seseorang masuk dan menerapkan malware ke NAS kamu, direktori yang terenkripsi juga nggak akan bisa jadi perlindungan karena malware tetap bisa menginfeksinya. Satu-satunya cara mungkin mencegahnya adalah dengan mengatur supaya folder terenkripsi harus autentikasi setiap kali akses.

Pahami bahwa enkripsi itu hal yang memakan siklus CPU berharga. Enkripsi itu nggak gratis.

Bagaimana kalau drive-nya dicuri? Yah, saya nggak tahu use case kamu, tapi untuk saya, rasanya nggak mungkin ada yang mencuri drive saya kalau ada yang membobol rumah saya. Kalau kamu di perusahaan, mungkin beda cerita, tapi itu berarti kamu harus punya kunci, pengamanan, dan kendali akses di ruang server. Saya nggak pakai enkripsi di PC saya. Saya mematikan fitur itu. Nggak ada sesuatu yang sangat berharga di perangkat saya sampai kalau hilang juga nggak masalah. Tetapi saya punya beberapa folder yang sangat spesifik di NAS yang dienkripsi dan berisi data keuangan serta info kesehatan pribadi. Itu juga sudah diatur di QuTS Hero dengan WORM.

Tapi nggak ada key atau hal semacam itu yang disimpan di folder home. Nggak ada. Pemakaian folder home pun cuma opsional.

Soal “Public” — ada beberapa folder “sistem” default yang dibuat QNAP (Public, Multimedia, dsb). Kamu nggak bisa menambah atau mengubah folder ini. “Public” itu folder yang bisa diakses semua user di NAS. Konsep “public” adalah folder yang bisa diakses semua user di perusahaan atau grup user. Kenapa kamu mau mengenkripsi folder ini? Itu kontradiktif dengan konsep public. Nggak semua folder di NAS kamu harus — atau pantas — dienkripsi! Kalau nggak mau pakai ya nggak usah. Dan ya, Public cuma bisa diakses di LAN kamu. NGGAK ADA SATUPUN bagian NAS kamu yang SEHARUSNYA diekspos ke luar (kecuali dari dalam container). Kalau kamu melakukannya, siap-siap saja kecewa.

9

Adil di beberapa poin: enkripsi tidak menghentikan malware, ACL-lah yang melindungi akses langsung antar pengguna, dan mengenkripsi folder Public pada dasarnya tidak ada gunanya. Saya tidak membantah itu.

Tapi itu bukan model ancaman yang diatasi oleh enkripsi data at-rest. Ini hanya melindungi satu kasus: drive keluar dari kendali Anda saat data masih ada di dalamnya. Ada tiga cara hal itu terjadi:

  1. Warranty RMA. Saya menjalankan 8 drive IronWolf dengan usia yang sama dalam satu RAIDZ2. Kegagalan sudah pasti terjadi, bukan “kalau”. Dan drive yang sudah rusak adalah drive yang tidak bisa Anda wipe — jadi, Anda harus mengirimkan data plaintext ke vendor atau menanggung biaya penggantiannya.
  2. Decommissioning atau penjualan ulang.
  3. Pencurian.

Tentang home directory: punyamu tampak kosong karena kamu belum menggunakan SSH key di unit itu. Punyaku ada folder .ssh. Begitu seseorang mengaktifkan login berbasis key, authorized_keys akan muncul di situ, dan pengguna sering menaruh private key tepat di sebelahnya. Bahkan daftar milikmu tidak sepenuhnya bersih — .bash_history menyimpan semua perintah yang kamu ketik, termasuk kredensial; .viminfo menyimpan potongan file yang kamu edit, termasuk konfigurasi; .composer bisa menyimpan auth token.

Itu sebenarnya inti argumennya: kamu tidak bisa menentukan sebelumnya folder mana yang akan menjadi sensitif. Data bisa bocor ke dotfile yang tidak pernah direncanakan. “Enkripsi secara default, kecualikan yang secara sadar saya nyatakan public” itu aman. “Enkripsi yang saya ingat sebagai privasi” berarti kamu harus selalu benar.

Biaya CPU: AES-NI. Pada hard disk berputar di atas 2.5GbE, AES bukan penghambat.

Satu catatan untuk keunggulanmu: enkripsi shared-folder dengan key yang disimpan agar otomatis unlock saat boot memang tidak membantu jika seluruh NAS dibawa pergi — ini hanya melindungi drive lepas. Namun untuk RMA, yang paling saya pedulikan, ini tetap berfungsi.

Saya juga menjalankan BitLocker di setiap mesin Windows di sini. Membiarkan NAS sebagai satu-satunya salinan plaintext dari data yang sama tidak masuk akal.

10

Tentu saja ada kunci enkripsi SSH yang disimpan di sana. Tapi sebenarnya itu adalah kunci publik. Klien bisa membuat kunci privat mereka sendiri yang kemudian ditukar dengan server, dan semuanya disimpan di mesin klien.

Kekhawatiranmu soal RMA dan pengembalian memang sah. Tapi menurutku, hal-hal seperti ini harus ada keseimbangan antara kenyamanan dan kebutuhan, dibanding kemungkinan sesuatu terjadi. Aku punya kunci di pintu depan rumahku, tapi kunci itu nggak berguna kalau seseorang memutuskan untuk memecahkan kaca di samping pintu, lalu menjangkau dan membuka kuncinya.

Aku selalu menganggap kunci dan keamanan sebagai cara untuk menjaga orang-orang iseng tetap di luar. Kalau seseorang benar-benar ingin masuk, mereka bisa dan akan melakukannya. Sekarang, aku memang sedikit lebih “serius soal kunci” dengan routerku dan mencegah akses, tapi tetap saja, aku yakin dengan waktu dan kesabaran yang cukup seseorang bisa saja masuk—tapi umumnya orang-orang jahat di internet mencari target mudah yang bisa diakses dengan cepat dan nggak butuh waktu lama untuk dibobol.

Ada jutaan penyakit di dunia ini yang bisa membuatku sakit atau bahkan membunuh. Tapi aku nggak hidup setiap hari pakai hazmat suit.

Keputusan ada di tanganmu cara menangani ini. Cara terbaik mencegah hal buruk di NAS-mu adalah dengan menjaganya tetap di balik firewall. Kalau kamu di lingkungan perusahaan yang butuh keamanan lebih, ya silakan enkripsi folder-foldermu.

Soal hard disk gagal di bawah RMA—oke, aku setuju soal itu. Tapi ada cara kamu bisa melindungi diri sendiri. Letakkan folder “sistem” (misal: Homes, dsb) di SSD. Aku rasa umumnya kamu nggak akan pernah perlu atau ingin melakukan RMA pada M2 SSD. Jadi semua hard disk biasa nggak akan menyimpan kunci atau konten serupa.

Tetap keputusan ada di tanganmu mau lakukan apa.

11

Hai Jon,
Saya sangat menghargai diskusi ini.

Memindahkan direktori home ke SSD memang sedikit membantu.
Kalau saya butuh private key untuk mengakses satu NAS dari NAS lain, biasanya key tersebut otomatis tersimpan di direktori home yang belum terenkripsi. Saya akan memindahkannya secara manual, tapi di situlah masalahnya—kita harus selalu ingat untuk melakukannya. Kalau sekali saja lupa, lalu hard drive dibuang tanpa erase yang aman, pintu masuk bisa saja terbuka.

Saya anggap pendekatan ini berbahaya, jadi saya akan coba meminimalkan risikonya. Banyak tips dari kamu yang sangat bermanfaat untuk hal itu.

Terima kasih banyak atas obrolan ini!

12

Ya, tidak masalah. Selalu menarik untuk mengetahui kekhawatiran keamanan orang lain.

Saya senang ini bermanfaat.