No, it does not because passphrases do not allow unattended boots. I want / need to be able to start / reboot my server without sitting next to it.
Good to know. Thanks. That makes the nextcloud and jellyfin use case obsolete for me.
1 Like
Got it! Thanks ! I very much appreciate for your time and patience.
I second that. Please consider setting up your own VPN like Wiregard and/or Tailscale (which relies on Wireguard). Setting-up Tailscale is extremely easy and scales very well. Pure wireguard is interesting also. I use both.
3 Likes
Sitting next to? You just login to the UI and unlock the dataset with your passphrase.
Ok. But still, this is not an unattended reboot. For example, after a power failure it will not recover without admin interaction.
1 Like
True but you canât have it all. You either want your data protected when/if itâs powered down or you donât.
TrueNAS Enterprise does have an option like the one you mentioned but thatâs only available on Enterprise systems.
Why do you say that? I have my data protected at rest AND the keys are in a remote location, downloaded during boot.
1 Like
Perfect. My point is for a free storage appliance using ZFS encryption keys or passphrase is going to cover 99% of use cases. I can see how your config goes that one step further but for most users itâs just not necessary.
Exposing an application like Nextcloud running in a container to the Internet is not exposing your TrueNAS. Many users do this and if you keep your Nextcloud updated, use a reverse proxy with TLS and strong passwords and/or 2FA is considered safe.
The warning not to expose your TrueNAS means the web UI and SMB and friends. Yes, people have been doing this.
4 Likes
Thanks for this clarification. That is pretty much how I currently do it with my debian server. I use nginx-proxy-manager to pass the traffic on port 80 and 443 to the respective docker container. And before the reverse proxy I have geoblocking and fail2ban with iptables.
Nevertheless, I believe a that at least he geoblocking and fail2ban part is not easily implemented with truenas. Not to mention the key management.
I do not want to create negative vibrations here. I very much like truenas as a home appliance. I like it more than openmediavault or unraid which I have tested too. I even purchased a license for unraid. And I tested this really heavily. But truenas is my winner in this trio.
1 Like
You can run custom docker compose. This topic can be helpful â Electric Eel - How I am using Dockerfile, .env files, compose files.
That is a good point. May be I just copy my existing nextcloud config (portainer stack) to truenas, tweak it a bit for folder names etc. and see if that works. I will do that!
Downloaded automatically during boot, which automatically unlocks your datasets?
I guess this has the advantage of deleting the keys on the remote server if your NAS is stolen.
Exactly. I simply take the keys offline.
2 Likes
Just to add my 2 cents here: in fact, I prefer neither. The GUI is fine to explore, experiment and learn. Specifically for TrueNAS it also serves as an indicator of what the user is supposed to do; if it is not featured prominently in the GUI, there be dragons 
In production I however prefer infrastructure as a code and I am managing (nearly) all of my homelab in Ansible. While the API is great and I have managed to script things I need, I would love to see an official TrueNAS collection. The https://github.com/arensb/ansible-truenas seems to be an independent effort that is incomplete and will necessarily lag beyond the development.
Here the Debian (or any setup that is not a locked-down appliance) install clearly wins.
1 Like
Just a quick note that I plan to use a network management software to monitor the health of my various devices including my ZFS NAS (letâs call it this way), but I donât know yet what to use.
I am quite satisfied with Observium.
Although not a direct option, could this not be scripted to run at startup using their API? I came across the following which could be of use: How to Unlock Encrypted Volume via API? - #4 by coolaj86
Good idea about storing the keys remotely so that you can disable access if the hardware is stolen. I store them off device as well but would like an option to decrypt the volumes automatically on boot (without storing on the same device) so may look into this.
2 Likes
Here is how I do it. This works for my main PCs with Endeavouros and debian as well as with my unraid test server. It works with LUKS and with native zfs encryption.
I have a private repo on github. This repo is not visible to other users. I have my keyfiles for zfs uploaded to that repo.
During boot, before importing zfs, I download the keyfile with:
curl -L -H âAccept:application/vnd.github.rawâ \
-H âAuthorization: Bearer $TOKENâ \
-H âX-GitHub-Api-Version: 2022-11-28â \
https://api.github.com/repos/<username>/<reponame>/contents/$keyfile \
-o $tmpfile &>/dev/null
The $TOKEN is the security token from github. $keyfile is the filename in the repo. $tmpfile is where the keyfile is being stored. This is in /tmp within an extra directory with restricted access rights so that the keyfile does not survive a reboot
That is reasonably save for me. A burglar steeling my hardware must have retrieved the keyfile before I get aware of the missing hardware. Otherwise I have enough time to take the keys offline or invalidate the $TOKEN.
And the github username that I use for this activity is unknown and can not be associated with my person. And the reponame is unkown and it is invisible anyways. That makes it very hard for a burglar to retrieve the keyfile upfront before they steel the PC. And why would they do this anyways?
Long story short, for a regular theft this is save enough.
For my 3rd box I went truenas bare metal. The hpe microserver did not have nvme so I bought a usb to sata ssd adapter and an m.2 sata ssd. Not mirrored but I keep config and setup on other nas devices.
Added sata.drive for vm storage.
Building similar system for a friend that does have nmve but not mirrored.
Ive not lost data in over a 2 decades. Have lost boot drive a couple of times but was always separate from data drives and not a big deal to recover from.
I would make sure whatever boot system you use, it can fully boot all by itself without user interaction.
Can you please elaborate?