{"id":9878,"date":"2026-05-11T15:45:31","date_gmt":"2026-05-11T14:45:31","guid":{"rendered":"https:\/\/innovatenews.site\/index.php\/2026\/05\/11\/i-built-the-weirdest-possible-nas-from-hardware-i-already-owned-and-it-works\/"},"modified":"2026-05-11T15:45:34","modified_gmt":"2026-05-11T14:45:34","slug":"i-built-the-weirdest-possible-nas-from-hardware-i-already-owned-and-it-works","status":"publish","type":"post","link":"https:\/\/innovatenews.site\/index.php\/2026\/05\/11\/i-built-the-weirdest-possible-nas-from-hardware-i-already-owned-and-it-works\/","title":{"rendered":"I built the weirdest possible NAS from hardware I already owned, and it works\u2026"},"content":{"rendered":"
\n

The topic I built the weirdest possible NAS from hardware I already owned, and it works\u2026<\/strong> is currently the subject of lively discussion \u2014 readers and analysts are keeping a close eye on developments.<\/p>\n

This is taking place in a dynamic environment: companies\u2019 decisions and competitors\u2019 reactions can quickly change the picture.<\/p>\n

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.<\/p>\n

Contrast that with Raspberry Pi units, which are not only limited on the OS front, but are also incapable of powering 2\u20133 drives (unless you invest in expensive HATs and adapters), and you can see why these ARM-based single-board computers aren\u2019t 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\u2019s more usable than it appears.<\/p>\n

\"\"<\/figure>\n

Although the TrueNAS on ARM project solves the CPU incompatibility issue with the ARM-based Raspberry Pi, the SBC also doesn\u2019t have a BIOS like typical x86 mini-PCs. So, unless a distro has been fine-tuned for the device, running any ol\u2019 Linux distribution (or even Windows, for that matter) requires a custom UEFI package \u2013 and that\u2019s where the now-archived rpi5-uefi repo by worproject comes into the equation.<\/p>\n

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\u2019d 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.<\/p>\n

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.<\/p>\n

Considering my previous experience with running Proxmox and Windows 11 bare-metal on the Raspberry Pi, I wasn\u2019t very confident about TrueNAS\u2019 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\u2019s possible to spin up ZFS pools on this makeshift setup. Since I wanted to gauge the TrueNAS-berry Pi\u2019s capabilities, I went with a 2.5G Ethernet adapter and plugged an SSD into the tiny board.<\/p>\n

\"\"<\/figure>\n

Once I\u2019d 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\u2019s really impressive for a project that involves running an incompatible distro \u2013 one that relies on the all-powerful ZFS under-the-hood \u2013 on something as weak as a Raspberry Pi.<\/p>\n

However, the TrueNAS app templates don\u2019t 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\u2019s all I could ask for in a barebones NAS.<\/p>\n

Despite their cute appearance, Raspberry Pi SBCs double as reliable server nodes<\/p>\n

Let me be clear: I can\u2019t 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\u2019s vastly inflated prices into the feasibility equation.<\/p>\n

That said, if you\u2019ve got a spare Raspberry Pi lying around, but don\u2019t 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).<\/p>\n