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.