The topic of I built the weirdest possible NAS from hardware I already owned, and it works… is currently the subject of lively debate — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
Building a Network-Attached Storage server from old hardware is the best way to repurpose systems that would otherwise gather dust into reliable backup solutions. While you could go for weaker systems released over a decade ago, most DIY NAS setups typically involve x86 machines capable of supporting at least a handful of storage drives.
Contrast that with Raspberry Pi units, which are not only limited on the OS front, but are also incapable of powering 2–3 drives (unless you invest in expensive HATs and adapters), and you can see why these ARM-based single-board computers aren’t ideal for NAS tasks. That said, I came across a community project that brought the all-powerful TrueNAS to ARM systems a few months ago, and after using it on my Raspberry Pi 5 for a while, I have to admit it’s more usable than it appears.
Although the TrueNAS on ARM project solves the CPU incompatibility issue with the ARM-based Raspberry Pi, the SBC also doesn’t have a BIOS like typical x86 mini-PCs. So, unless a distro has been fine-tuned for the device, running any ol’ Linux distribution (or even Windows, for that matter) requires a custom UEFI package – and that’s where the now-archived rpi5-uefi repo by worproject comes into the equation.
Fortunately, rpi5-uefi is fairly easy to run on the Raspberry Pi, as all I had to do was format a microSD card to FAT32 and paste the extracted files in its root directory. But since the microSD card is meant to serve as the UEFI partition, I had to use a USB-powered device for the TrueNAS installation drive. Ideally, you’d want to use an SSD for the boot drive, but since this was a wacky project to begin with, I went with a cheap flash drive instead.
But the biggest caveat of the rpi5-uefi package is that it renders the EEPROM module, GPIO pins, PWM control settings, and Ethernet port unusable on any distro I attempt to boot with this setup. Considering the N in a NAS stands for Network, the last one is a deal-breaker for a makeshift storage server. That said, using a USB-to-Ethernet adapter solves this problem, leaving just two slots for the hard drives. And in all fairness, a Raspberry Pi tends to run into issues when powering multiple drives (especially HDDs) without additional accessories, anyway.
Considering my previous experience with running Proxmox and Windows 11 bare-metal on the Raspberry Pi, I wasn’t very confident about TrueNAS’ performance on the SBC. However, the community port works surprisingly well for simple NAS operations. Sure, the TrueNAS dashboard may have trouble identifying the processor, but it’s possible to spin up ZFS pools on this makeshift setup. Since I wanted to gauge the TrueNAS-berry Pi’s capabilities, I went with a 2.5G Ethernet adapter and plugged an SSD into the tiny board.
Once I’d created a new storage pool, I began tinkering with the network share settings and user profiles. Creating a new account for accessing the shares was easy, and the same applies to the SMB share creation process. Within a minute, I was able to log in to the SMB share on my PC, and my spare drive was able to transfer files at a steady 210MB/s. That’s really impressive for a project that involves running an incompatible distro – one that relies on the all-powerful ZFS under-the-hood – on something as weak as a Raspberry Pi.
However, the TrueNAS app templates don’t work on the ARM-based SBC, but it wasn't too much of an issue, since I can simply deploy custom LXC containers anyway. Rsync tasks work surprisingly well, and the same applies to scrub tasks. Honestly, that’s all I could ask for in a barebones NAS.
Despite their cute appearance, Raspberry Pi SBCs double as reliable server nodes
Let me be clear: I can’t recommend using a Raspberry Pi as a dedicated NAS. Even leaving the Ethernet and UEFI workarounds aside, an x86 machine is always better for a primary storage, archival, and backup server, even more so once you factor the Raspberry Pi’s vastly inflated prices into the feasibility equation.
That said, if you’ve got a spare Raspberry Pi lying around, but don’t have the money to build a dedicated 3-2-1 backup pipeline, this setup can act as an offsite server. Pair it with an OPNsense router armed with Tailscale (or even a subnet router running on another PC), and the TrueNAS-berry Pi rig is pretty useful at pulling rsync tasks from a local node. Or, you could just use it as a redundant backup/cold storage machine (though you might want to avoid using SSDs for long-term storage, as they can lose data if you leave them unplugged for a couple of months).
Why it matters
News like this often changes audience expectations and competitors’ plans.
When one player makes a move, others usually react — it is worth reading the event in context.
What to look out for next
The full picture will become clear in time, but the headline already shows the dynamics of the industry.
Further statements and user reactions will add to the story.