I Thought TrueNAS would be cool, but..(No Option for SMB Transport Encryption?)

An open source, Linux-based, GUI-friendly NAS OS seemed like a good deal to me, so I install TrueNAS SCALE 24.04.2.2 on a newly built machine.

The first thing I noticed was that it didn’t offer anything for boot device encryption. Okay, weird, but maybe CORE does since BSD has GEOM ELI? Reinstalled with CORE and also nope. Very disappointing that this whole software suite doesn’t have any option for boot device encryption, seeing as this has been a standard feature of Linux, BSD, and Veracrypt on Windows for over a decade.

But whatever. I can live without it. Moving on. Set up a dataset (at least that has encryption) and made it an SMB share. Now I see that neither the SMB global config nor the specific share config has anything in the GUI about transport encryption. Whut? Docs here (SMB | TrueNAS Documentation Hub) say it exists, but must be outdated, because the encryption options have been removed from the GUI in the latest version (see pic).

Seems like kind of an important thing to just delete from the GUI, no?

So whatever, I guess security isn’t user-friendly. So I open the shell and try to edit the config file. It’s not there. Whut? Whatever, I’ll create another one. It asks me for a sudo password, which succeeds, and access is denied anyway because I wasn’t allowed to create a root account during the install process.

Can anyone give me any advice on enabling/configuring SMB transit encryption in this OS? I really wanted to like it, but it seems security is just not a priority at iXsystems, so I’m probably gonna just trash it and go with Debian or CentOS instead.

FWIW, the initial install failed at almost every step, too, and required like four hours of debugging. Even the iso download failed the checksum. Twice.

Very unimpressed. Hoping for hope to be restored.

Oh, and first post on the forum. Hello everyone. Your troubleshooting has been a wonderful resource for the past six hours of nonsense and nonfunctionality. Thank you.

2 Likes

That is always the wrong answer in TrueNAS.

Those docs are for a version of SCALE that won’t exist for another 6 months or so.

Okay, SSH had the same result, too. ¯_(ツ)_/¯

If security is a priority you can configure your SMB clients to negotiate encrypted transport (which is probably rather important if it’s a priority). This has been supported through negotiation for a very long time. We are exposing option to force encryption server-side in Electric Eel.

1 Like

Just noting here that those docs are, at this point, at parity with the 24.10 (Electric Eel) docs: https://www.truenas.com/docs/scale/24.10/scaletutorials/systemsettings/services/smbservicescale/#configuring-transport-encryption. No 25.04 specific changes have been made to the SMB docs so far afaik.

24.10 is due for stable release this month.

Thanks for the prompt staff responses, guys, I appreciate it. I suppose I’ll have to wait six months to force SMB encryption. I see also that the auxiliary parameters textbox (which I gather has once existed, based on historical posts) is missing as well.

Any tips to force SMB encrypted transmission and select protocols using shell/GUI in my current version? Maybe reinstall when Electric Eel is stable?

Also, any plans to allow for boot drive encryption with LUKS/GEOM?

Got too many clients with too many private devices for this to be feasible. Is forcing encryption server-side not an option, at all, in SCALE 24.04.2.2?

Less than one month. Electric Eel is on RC.2 and very close to the stable release. @dan was referring to the 25.04 (Fangtooth) docs you had originally linked to.

Rad, thanks for the heads up.

If you are still prototyping you can easily upgrade to RC2 and start testing with this functionality now:

Pretty painless to upgrade that to the -RELEASE when it drops at the end of the month.

Nope:

So less than a month if all goes well.

Guess I got in at the right time. I should point out that crapware like Synology has had this option for years. Thanks for the clarification gentlemen.

At present, encrypting the boot pool is not available. No confidential data is installed on the boot pool, with one exception. Those desiring boot pool encryption sometimes want it for theft prevention of the NAS server.

The exception to information stored on the boot pool, is the encryption keys. This is intended to allow automated reboots without SysAdmin interaction. The data on encrypted Datasets & zVols are still protected against disk returns and plain disk theft.

If their is a need for preventing automated reboots from unlocking encrypted ZFS Datasets & zVols, then you must use Passphrase / Password encryption. Upon all reboots, the SysAdmin must log into the web GUI and manually unlock those Datasets & zVols

This storing of encryption keys in the boot-pool is not a ZFS thing, it was a design choice for Enterprise TrueNAS. Whether it was the right one or not, is a discussion for another thread.

Last, when using ZFS encryption key method, it is always required to download a copy in case of boot pool device failure. (Of course, storing any ZFS encryption using passphrase / password should also have that stored in a password vault.)

1 Like

Thanks to everyone for your replies. The explanation of the mechanics of encryption in the Linux kernel was probably helpful to someone who will read this at some point. I will look forward to the release of 24.10. The end user of the system I am working on is dead-set on a GUI environment, and TrueNAS has that in spades. I will continue to develop this build and try to post on this forum when issues crop up. I am primarily making this post in case it is required to create a new thread in the forums, as the “new thread” button seems to be missing. In my case, I will be pushing SMB encryption client side, somehow. My latest issue has to do with a containerized install of NextCloud…

For the containerized install of Nextcloud, will be easier on Eel and plenty of docker compose examples for it should you want to do more than the built in app.

Thanks for the heads up. I would switch to the RC, but wouldn’t be responsible on a production device. I’ll wait.

I would like to start a topic on this containerization issue I have, but the button to start a new topic has disappeared for me, I think. Maybe you could help me? Off-topic for the present forum, though.

What about the syslogs, which are now forced to live on the boot-pool, in which it was possible to locate them on the System Dataset (which can inherit the root dataset’s encryption, and thus be encrypted)?[1]

Some logs can be “chatty” and reveal filenames on the pool, such as log.smbd, depending on the “Log Level” set in the SMB options.


  1. It’s still possible in Core 13.3, and it’s how I have it set up. ↩︎

That seems like kind of a big deal

1 Like

Log level should never be set above MINIMUM for production environments. Everything else is for debugging purposes only.