Creating a two drive raidz1 - or "How to make TrueNAS accept your orders"

Desperate situations require desperate solutions

A friend of mine bought two used 8TB external hard drives for their TrueNAS, and I got tasked with making them run. So I went through the same procedure as with the other drives in that box (cracking them open, add them to the system, run smart tests, etc), and validated their health and usability. Since they wanted to have some redundancy while also thinking about adding a third drive which they had lying around (but which was full to the brim with data) later, I needed to get creative. Setting up a mirror would deny the option to expand the pool with the third drive, buying even more drives was not a good option for them financially either. So I thought about a raidz1 pool, but TrueNAS being TrueNAS, the web UI does not allow for the creation of a two drive raidz1. And it makes sense. Why would you create a raidz1 on two drives, it is essentially just a mirror, but with computing overhead for the parity calculations. But TrueNAS does not know about our plans. Creating a virtual file as a placeholder drive would require a large enough drive to actually hold that file — which would make the entire idea obsolete anyway. The only other option would be to remove the file after pool creation, leaving the pool in a degraded state from the start.

Disclaimer

What I am about to do (or have done) is not the way TrueNAS and iXsystems want you to do this. This is my very specific solution to a very specific problem. If you want to try this yourself, only do it when you are absolutely sure about what you are about to do. Dataloss is a very real danger, and I am not responsible for any issue happening on your system. Backups are not just fancy ways to brag, they save your butt.

The Plan

Considering the need for at least enough storage to empty the third drive and the wish to expand the pool later on, I came up with the idea to “negotiate” with the CLI. ZFS supports raidz1 on two disks, just TrueNAS wants to babysit me. Which also makes sense. iXsystems certainly does not like angry callers about broken franken-raids. So I created the raid manually via

zpool create -f -m /mnt/<poolname> <poolname> raidz1 /dev/disk/by-id/<drive1> /dev/disk/by-id/<drive2>.

When I say I want a raidz1, I get my raidz1. I don’t care what middleware (or the web UI) with its overly protective syndrome wants. I know that I am operating within the specs of ZFS, I understand that this is inefficient at best and a nightmare to maintain later on at worst. But a few seconds later, we had a healthy raidz1 pool on two disks. Now we just needed to make TrueNAS aware of it, which turned out to be a whole different can of worms, but not too much effort either.

Making TrueNAS accept your will

So after creating the pool, I went on to import it via the web UI, which worked fine. Just until I tried to create a dataset on it. TrueNAS reported that it could not create a new dataset on the mountpoint /mnt/mnt/<poolname>. Oh, neat, TrueNAS tried to be helpful and just prepended the /mnt to the path it read from the pool to have it in a central mount location. Okay, lesson learned: don’t create the pool with /mnt in its path, so I destroyed the pool again and tried to recreate it using the same command, just without the /mnt in the path. And the CLI complained about not being able to mount it on the readonly location /. Urgh, okay. I started to get a bit annoyed, because how am I supposed to create the pool if I can’t set the path to its final version, while also not being able to set the path in a way TrueNAS expects, so middleware does not get confused? Some digging in the internet (and making use of a LLM) later, I cooked up this solution:

• Destroy the pool (again)
• Recreate the pool (again) with the fullpath (/mnt/<poolname>), so ZFS can create the pool
• export the pool with zpool export <poolname>
• reimport the pool with zpool import -N -R /mnt <poolname>, so the pool gets mounted at a specific location (/mnt in this case), but does not touch any filesystems on it. Perfect for just changing some metadata about the pool.
• changing the mountpoint stored in the pool with zfs set mountpoint=/<poolname> <poolname>, so TrueNAS gets its expected (somewhat) relative path and the fullpath becomes /mnt/<poolname> after TrueNAS prepends its mount location.
• export the pool again with zpool export <poolname> to flush the changes made to the pool metadata to the drive
• import the pool using the web ui

It certainly is not pretty, it’s also not recommended, not even by me, but it certainly looks funny, when TrueNAS shows you a valid, healthy two wide raidz1 in the UI, without noticing anything weird about it. What followed after, was the usual stuff, creating datasets, changing permissions, creating SMB and NFS shares, mount the pool on my friend’s laptop, business as usual.

Final thoughts

Should you do this? No, unless you know exactly what you are doing and which gods you are about to anger. Is it my solution to a very specific problem? Yes.