Can the `homes` shared folder be encrypted in QuTS hero?

English Storage
1

The homes shared folder shows no encryption option in the UI. It appears to be created
and managed automatically by the system when home folders are enabled, rather than through the
normal “Create Shared Folder” dialog where the encryption checkbox lives.

Since ZFS cannot enable encryption on an existing dataset (zfs get shows encryption as
EDIT: NO), this looks unfixable after the fact.

This matters because home folders here will hold real personal documents

Questions

  1. Can the homes shared folder be encrypted at all in QuTS hero? Is the absence of the
    option a deliberate design limit, or am I looking in the wrong place?

  2. If home folders are disabled and re-enabled, is the underlying dataset recreated — and
    if so, can it be created encrypted?

  3. Is there a supported way to place home folders inside an encrypted shared folder, or to
    point them at a dataset I created encrypted myself?

  4. If none of the above: what do people do instead? My current plan is to keep homes
    minimal — only what the appliance itself needs — and give each user a normal encrypted
    shared folder for their actual documents, mapped as their drive. Is there a better
    established pattern?

2

The homes folder is an optional thing in QuTS (and I think QTS). You don’t have to enable it. It may have some Linux applications, but because it is somewhat of an “OS” type folder, you really can’t (nor would you want to) encrypt it. You are better off giving users their own encrypted shared folders stored elsewhere. Encrypted folders can be dangerous as if someone loses their encryption key, there is no way to recover the data. Also, backups don’t work either if the encrypted folder is locked.

You can’t move the “homes” folder and its hierarchy.

I don’t think you can encrypt a specific “folder” in QuTS. In QuTS Hero, you need to create a shared folder and chose the encryption open when you create that shared folder. Keep in mind that each shared folder is treated as its own volume in QuTS. You will then need to apply the permissions for the users for each of these shared volumes.

3

Thanks for the advice — I disabled home folders and then ran into something worth documenting.

With home folders disabled, /share/homes is not removed. It is re-pointed at a placeholder:

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

So /share/homes becomes a 128 MB RAM disk. /etc/passwd still lists /share/homes/<user> as the home directory, so shell users get a home that lives in tmpfs. I confirmed this by rebooting: the home directory was wiped. I had manually copied my .ssh folder there to keep key-based SSH access, and it was gone. Luckily I had verified password login beforehand, otherwise I would have locked myself out.

My question: if someone deliberately does not want to use the built-in home folders feature, what is the supported way to set this up? Specifically:

  1. Is there a supported way to point a user’s home directory at a normal shared folder, one that survives reboots and firmware updates? Editing /etc/passwd directly seems pointless since it is regenerated at boot.
  2. Is the tmpfs redirect intentional, or is it a fallback that was never meant to be run in permanently?
  3. For SMB users, is there any way to make separate (encrypted) shared folders appear inside a single folder tree, other than mapped drives or a Windows DFS namespace? Symlinks are blocked by Samba’s wide-links restriction, so those are not an option.

Ideally I am looking for a stable, documented layout rather than a workaround that breaks on the next firmware update.

4

I don’t think there is a supported way to do this, so I use one single encrypted shared folder for all users but use ACL to disallow users accessing other people’s files.

5

I am not aware of any way to do what you are asking. You may be able to set things up in a boot/login script but not sure. Someone else may be able to comment.

Why don’t you do this instead:

  1. Leave the user’s home folders enabled and as-is.
  2. Create an encrypted share for each user where they put their data needing to be encrypted.

What is your reason for wanting encryption of EVERYTHING a user has on the NAS?

6

Thanks for your question! I’ll forward it to our internal team to discuss the issue you raised.

7

Thanks for the recommendation: I’m going to set up an encrypted volume for the users (a people share) and use that as their $HOME. However, there is always a risk that keys and other private data could end up in the default, unencrypted homes share. That is essentially unacceptable to me.

I’m a bit surprised by the question of why everything needs to be encrypted these days—especially the home directory. After all, that’s where private keys and private data are stored. I’m currently migrating from Synology (Synology feels a bit dated and seems to lack further development ambitions, whereas QNAP comes across as much more ambitious; so, I don’t regret switching to QNAP). But I had everything encrypted on my Synology NAS for years, too. It’s the same with Windows: BitLocker encrypts all drives and file systems. What if the hard drives get stolen? End-to-end encryption is essential. Zero Trust.

The same applies to the public share. I can neither remove nor encrypt it. Even though it’s called public, it’s only accessible within my LAN, not to the outside world. QNAP really ought to give this some serious thought.

8

Uh, there are no private keys and “private” data stored in the home directory. I’m not sure where you get that idea.

This is the home directory of the admin account on one of my NAS units:

[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 ~]#

There is nothing there that is keys or any kind of “private” user data. The only private data that a user might put in there is data that they determine is private and then if THEY want to protect that they can do so by using encryption on their own folders.

I believe you are way, way, way overthinking this.

If you have a multi-user NAS system that is properly protected from the internet (ie: not exposed), then the security between user access is your passwords and ACLs. One user cannot access another user’s home directory w/o proper ACLs. Now, maybe one user could try hacking their way, but that person is likely going to be trying to do other bad things rather than access a random user’s file. Additionally, if someone comes in and applied malware to your NAS, an encrypted directory will be a useless defense as the malware will still infect it. They only way to possibly prevent that is to set things in the encrypted folder so that you have to authenticate every time you access it.

Understand that encryption is a thing that takes up precious CPU cycles. It doesn’t come for free.

What if the drives are stolen? Well, I’m not sure of your use case, but in mine, I doubt someone would be going to take my drives if they broke into my house. If you are in an enterprise, maybe but then you should have locks and keys and access control on your server room. I don’t use encryption on any of my PCs. I turn it off. There’s nothing that I have on them that is so valuable that if I lose the laptop or machine that it would hurt me. I do have some very specific folders on the NAS encrypted that contain personal financial and health related info. It’s also set up in QuTS Hero with WORM.

But there are zero keys and things stored in the home folder. None. It’s optional to even use it.

As for “Public” - there are certain default “system” folders that QNAP creates (Public, Multimedia, etc). You can’t not add these or change them. “Public” is a folder that all users on the NAS have access to. The concept of “public” is a folder that all users in an enterprise or user group have access to. Why do you want to encrypt it? That’s against the concept of public. Not every folder on your NAS needs to be or should be encrypted! If you don’t want to use it then don’t. And yes, Public is only accessible on your LAN. NOT ONE PIECE of your NAS should EVER bet exposed to the outside world (the only exception would be exposure from inside a container). You are asking for many tears if you do.

9

Fair on several points: encryption doesn’t stop malware, ACLs are what protect live access between users, and encrypting Public is pointless by definition. I’m not arguing otherwise.

But that isn’t the threat model at-rest encryption addresses. It covers one case: a drive leaving your control while data is still on it. Three ways that happens:

  1. Warranty RMA. I run 8 IronWolf drives of identical age in a single RAIDZ2. A failure isn’t “if”. And a drive that has already failed is a drive you cannot wipe — you either ship your plaintext to the vendor or eat the cost of the replacement.
  2. Decommissioning or resale.
  3. Theft.

On the home directory: yours looks empty because you haven’t used SSH keys on that unit. Mine has a .ssh folder. The moment anyone enables key-based login, authorized_keys lands there, and users routinely park private keys right next to it. Even your own listing isn’t clean — .bash_history holds every command you’ve typed, credentials included; .viminfo holds fragments of the files you edited, configs among them; .composer can hold auth tokens.

Which is the actual argument: you don’t get to decide in advance which directory turns sensitive. Data leaks into dotfiles nobody planned for. “Encrypt by default, exempt what I consciously declare public” fails safe. “Encrypt what I remember is private” requires being right every single time.

CPU cost: AES-NI. On spinning disks over 2.5GbE, AES is not the bottleneck.

One caveat in your favour: shared-folder encryption with the key saved for auto-unlock at boot doesn’t help if the whole NAS walks out the door — only against loose drives. Against RMA, which is the case I care most about, it works either way.

I also run BitLocker on every Windows machine here. Leaving the NAS as the one plaintext copy of that same data doesn’t add up.

10

Sure there’s an SSH encryption key stored there. But really that’s a public key. The clients can generate their own private keys exchanged with the server and those are all store don the clients machine.

Your concerns are valid about RMAs and returns. However, I kind of view stuff like this as a balance of convenience and needs against the odds of anything happening. I have locks on my front door, but that lock is useless should someone decide to break the glass pane next to it, reach in and unlock my door.

I always view locks and security as a way to keep the casual interloper out. If someone really wants to gain access they can and will. Now, I’m a bit more “lock and key” with my router and preventing access but still, I am sure that with enough time and patience someone could gain access but generally the bad interlopers on the net are looking for the easy pickings that can be accessed quickly and don’t take a long time to hack.

There’s millions of diseases in the world that can make me sick and kill me. But I don’t walk around my life in a hazmat suit.

It’s your call how you want to do it. Best way to prevent bad things on your NAS is to keep it behind your firewall. If you are in a corporate environment where you need more security - sure encrypt your folders.

As far as failed drives under RMA - sure I’ll give you that. But here’s how you can protect yourself. Put the “system” folders (ie: Homes, etc) on SSD drives. I would expect you would generally never need/desire to RMA an M2. SSD drive. Then all the spinning discs would not have any of those keys or similar content on them.

Still your call how you want to do things.

11

Hi Jon,
I really appreciate this discussion.

Moving the home directory to an SSD actually helps a bit.
When I need private keys to access one NAS from another, they end up in the unencrypted home directory by default. I’ll move them manually, but that’s exactly the point—you always have to remember to do it. Forget it once, and if you later dispose of the drive without a secure erase, you’ve left a potentially open door.

I consider this approach dangerous, so I’m going to try to minimize the risk. Many of your tips were very valuable for that.

Thanks a lot for this exchange!

12

Yeah no worries. It is always interesting to learn about the security concerns of another.

I am glad this has been useful.