Why there is no need to enter encryption key after Reboot? In LUKS you need to enter passhrase

Hi

Why there is no need to enter encryption key after Reboot? In LUKS you need to enter passhrase…

If a thief steals my NAS and boots it at home, the disks are exported unencrypted, correct?

Thanks

If you’re using a key instead of a passphrase, TrueNAS saves it in the config database on the boot drive so that the datasets can be readily available after a reboot without user intervention.

Should there be an option to require manually unlocking for key-based encryption? Make a feature request?

The reason they made it this way is so that the System Dataset and “Apps” will not break after a reboot, since there wouldn’t be an accessible filesystem for them to use.

2 Likes

Thanks. I deleted the pool again and tried to setup a new pool with custom passphrase. I can’t find such option.

I wish to use password like this

pwgen -n1 -c 56 -y
aigaeSh3em2bu6eiph5ahtao3taiJuPh9Nei2aing4WooRei|phu6eeh

If you use a passphrase, you won’t be able to put the System Dataset or any Apps on it.

You don’t see an option to use a passphrase? The GUI gives you the choice.

Read up on the risks and caveats. You’re not encrypting a pool. You’re encrypting its root dataset and any children that inherit it will also use encryption.

Don’t lock yourself out of your own data.

1 Like

Consider this idea as well. It’s 100% compatible with using key managers and vaults, but adds an extra safeguard from losing your data.

The hash can be used as a “passphrase” instead of a key, to suite your requirements.

2 Likes

I can’t find it. Sorry!

I guess they don’t allow you to choose the format when creating a pool.

You’ll have to change the root dataset’s property after you create it. Switch it from “Key” to “Passphrase” for its encryption property. This should be accessible from the Datasets page.

1 Like

STOP!

Don’t ignore that warning about the serial numbers. Are you using a USB enclosure?

2 Likes


I have 2 tiny disk 4 MiB × 2. I don’t know why? I think those two disks generate the error, see screenshots.
No USB Enclosure. Strange two SSD disk

I found the passphrase. But this is not a “normal” passphrase

I would avoid using a super special character like a pipe | that you included in your password (which was hopefully just an example). It has a specific meaning in the *nix world and I personally think it’s an unnecessary risk.

Can you please post full hardware details? That warning about non-unique serial numbers can be a big deal. I’ll point out that you got that warning even when you didn’t have 2 tiny drives of unknown origin in your list of unassigned devices.

Don’t rush this.

OS Version:25.04.2.5

Product:DXP2800

Model:Intel(R) N100

Memory:7 GiB

It’s the eMMC that does this - most of these devices present it as multiple mmcblk devices and that trips the middleware warning.

Don’t create a pool on them (and at 4MB, you can’t) - and it should be okay.

3 Likes

That’s not the passphrase input. That’s where you input your own HEX string (key).

You have to change the format from key to passphrase.

To be safe, use @neofusion’s advice on avoiding super special characters.

2 Likes

Thanks, found it. It gives error:


Only one layer above it worked.

Is it a security risk to have in root zpool “Type Key”?

That’s because of this:


Not really. You won’t be saving anything directly inside the root dataset’s filesystem. The only other data that will be accessible to anyone with access to the server is the contents of the System Dataset, the Apps dataset[1], and the system logs.


  1. IIRC, The Apps dataset are enforced with “unencrypted”. ↩︎

1 Like

Thanks for your help

1 Like

Are they really exposed? Don’t you need to login to get to the webinterface?
Also my Smb shares need to login before getting any access.
If you still can get the keys from the boot media it would be kind of useless to encrypt?

They keystring is stored in the config file on the boot-pool. The boot-pool is never encrypted.

Simply having access to the boot drive is all that’s needed for someone to retrieve the keystring. (The files freenas-v1.db + pwenc_secret allows someone to extract the keys for all your encrypted datasets.)

Here’s an example of retrieving the keys with the two files, which are stored on the unencrypted boot drive.

1 Like

So why encrypt, when someone with access to the server can simply get the encryption keys?