Despite switching between multiple distros during my home lab journey, TrueNAS Community Edition (or Scale, as it was called back in the day) is hands-down my favorite of the bunch, as it has the holy trifecta of solid data protection features, powerful ZFS roots, and top-tier performance. Unfortunately, it’s restricted to x86 systems, leaving OpenMediaVault as the only popular NAS distro for Arm devices like the Raspberry Pi. That’s a shame, because certain high-end Raspberry Pi devices have enough memory to meet the minimum requirements for running ZFS pools.
But considering the talented Raspberry Pi community, it shouldn’t come as a surprise that the genius developer Joel0 created an Arm variant of this uber-powerful NAS distro. The moment I saw the unofficial TrueNAS Arm port, I knew I had to deploy it on my Raspberry Pi 5 (8GB) to see how well it holds up. While it has some problems, I’m really surprised by how well this image works on the latest and greatest Raspberry Pi. If you’re curious, here’s a log of the entire experiment.
Setting up TrueNAS requires a few more steps than usual
Mostly because the Raspberry Pi needs a UEFI image
Most Raspberry Pi distros have a simple setup procedure – once you’ve flashed the .img file onto a microSD card (or another storage device), you can slot it onto the SBC and get on with your project. Well, the keyword here is most, because there are certain community-created ports that require you to use a UEFI to boot into the modified operating system. The Arm variant of TrueNAS is no exception, and since the Raspberry Pi lacks moddable UEFI facilities, the first step was to grab a package that could add UEFI support to the SBC.
I’ve previously used the RPi5 UEFI package from WoR Project’s GitHub repository when setting up Windows and Proxmox on my tiny tinkering companion, but it has since been archived. While there are forked versions of the repo, I decided to go ahead with this version. Configuring it is fairly simple, as all I had to do was unzip the repo, plug a microSD card into my PC, and copy the files onto a FAT32 partition. However, the Raspberry Pi 5 UEFI settings tend to break certain aspects of the SBC, one of which is essential for a TrueNAS setup…
The Ethernet options are somewhat limited
If you use the RPi5-UEFI to boot into an OS, the EEPROM module, PWM control, and GPIO pins stop functioning. While they aren’t that big of a deal, the lack of support for the built-in Ethernet port is a huge problem considering TrueNAS is meant to be hooked up to your LAN. But since I didn’t have an Ethernet HAT at the moment, my solution was to go with a USB-to-RJ45 adapter. Sure, they may not be ideal for a NAS, but I’ve previously used one with my Raspberry Pi firewall, and it worked without any issues for a few months. This time, I went with a 2.5G interface, since the USB 3.0 port on my RPi 5 could handle the faster Ethernet standard.
Then there’s the storage problem. Since the Raspberry Pi UEFI hogs the microSD card, I’d have to come up with a different storage device for the TrueNAS image. Worse, since it’s just a bootable image, I’d have to slot yet another device as the boot drive. So, my game plan was to flash TrueNAS onto a USB drive and use the installation wizard to install the OS on a fast 128GB USB 3.2 Gen 2 flash drive.
Once I plugged everything into the Raspberry Pi, I used the UEFI to boot into TrueNAS. The setup wizard was identical to what I’m used to when configuring TrueNAS on x86 machines. After selecting the USB 3.2 Gen 2 drive as the installation device, I entered a password for the truenas_admin user. With that, the Raspberry Pi began installing the all-powerful NAS OS, and although it took quite a few minutes for the installation wizard to work its magic, TrueNAS was successfully configured on the tiny board.
TrueNAS works pretty well on the Raspberry Pi
The transfer speeds weren't bad by any means
With TrueNAS configured, it was time to log into the web UI and add a ZFS pool to my NASberry Pi. Interestingly enough, the distro couldn’t identify the CPU, though the memory utilization section worked perfectly fine. As for the storage device, I slotted a SATA SSD into an external drive enclosure and plugged it into the USB 3.0 port on the SBC.
Afterward, I switched to the Storage pool tab and, since I was only interested in testing whether Raspberry Pi could choke the 2.5G connection, I configured it in a Striped pool. Then, I went through the usual procedure of creating a user and adding it to a newly configured SMB share.
Once I connected my PC to the SMB share, I began transferring huge ISO files. For reference, my PC and switch were on a 10GbE setup to avoid any potential bottlenecks from the client or the network stack. The RPi consistently hit over 210MB/s, even reaching 225MB/s at times.
Running CrystalDiskMark provided similar results, and I was pleasantly surprised by the fast transfer speeds.
Unfortunately, TrueNAS apps are a broken mess
I also configured some remote sync tasks and scrub operations on the NASberry Pi, which worked just as well. Sadly, the built-in App Store wasn’t functional for me. Sure, I could browse the usual collection of apps, but I ended up getting error messages when I tried installing my favorite self-hosted services. The only applications I managed to deploy were WireGUI and Tailscale, though both would crash as soon as I tried to run them.
That said, I was able to deploy a Debian container from the Containers tab. With the usual commands, I armed it with some lightweight Docker containers. But nothing too crazy, as I didn’t want the server to come crashing down.
How feasible is this project, anyway?
When I previously ran Windows 11 and Proxmox on the RPi 5, the SBC’s performance was far from decent, so I had low expectations going into this project. However, I’d call it a huge success. Sure, it may not be able to hit the theoretical max limit of a 2.5 Gigabit connection, but the fact that a mere Raspberry Pi could host TrueNAS-based ZFS pools at solid performance is quite the feat. Running containers – albeit in a convoluted manner – was the cherry on top. With a well-configured Tailscale instance, I can see myself using the NASberry Pi as a remote ZFS-powered backup server.