TrueNAS Scale NAS platform was designed to work on x86-64 computers only, but there’s now an unofficial port for 64-bit Arm (Aarch64) targets running a UEFI bootloader, including the Raspberry Pi 4/5 SBCs and other higher-end Arm boards.
Previously known as FreeNAS, the community edition, FreeBSD-based TrueNAS Core was phased out in 2022 and replaced with the Linux-based TrueNAS Scale. iXsystems also provides TrueNAS Enterprise, a paid version with more advanced features, but all versions only work on 64-bit x86 machines. TrueNAS forum user Joel0 decided to change that and patched TrueNAS Scale to run on ARM (aarch64).
The main requirements are having a 64-bit Arm target, at least 8GB RAM, 16GB boot storage, and a working UEFI bootloader. The image has been tested with a QEMU virtual machine, and it should also work on a Raspberry Pi 4 or 5 with UEFI, but it has not been tested. One user from the forum thread above has tested it on a Mac Studio M4 with VMware Fusion. The only known issue at the moment is that apps and containers do not work.
This could, for instance, enable a TrueNAS on a Raspberry Pi 5 fitted with a Radxa Penta SATA HAT as pictured above. Arm SystemReady-compliant boards like the Radxa Orion O6 should also be candidates, and even Rockchip RK3588 SBCs could be used since there’s an EDK2 UEFI firmware port that works on the FriendlyELEC CM3588 NAS kit, among many other boards.
If you want to get started and/or help with the projects, there are three main resources to look at:
- The ISO image (TrueNAS-SCALE-25.04.2-aarch64.iso) to run TrueNAS Scale on a 64-bit Arm target
- The source code at https://git.jmay.us/truenas/
- The issue tracker on GitHub. The repo is only used as an issue tracker, and there’s no code there.
There’s not much in the way of documentation, but I’m not sure it’s needed, since users simply need to be able to load an ISO image and follow TrueNAS documentation for installation and configuration. There’s also a recent interview of Joel May about the port on TrueNAS Tech Talk.
Via Jeff Geerling
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
“16GB storage” ? Ouch! What do they put on that NAS, does it come with 4K video howtos to explain how to configure it? It’s 1024 times heavier than mine! It means it excludes boards like the Rock5 ITX (8GB eMMC) which definitely is one of the best boards for such a use case, especially when you combine it with a 10GbE NIC on the main M.2 slot. Well, it’s possible to hack with M.2 converters to install a small SSD vertically on the wifi slot like I did but that’s dirty and few people will do that. It’s amazing how laziness or incompetence or both are causing hardware obsolescence these days…
Quoting Joel from the forum thread: ‘The minimum requirements will essentially be the same as the regular release.’
And those minimum requirements IMO were never be technically driven but from a support POV (force users to not use crappy hardware).
The FreeNAS forum or their moderators is also infamous for creating the ‘ZFS scrub of death’ myth which is BS but from a support perspective great advice since nudging users to get server grade hardware. A machine with ECC RAM usually also has reliable storage controllers and this is where it got really ugly with ZFS in the early days: crappy storage controllers ruining data.
But my understanding is that FreeNAS was always made to reuse old or limited hardware. Here we’re seeing it on an RPi, which is exactly in this direction. A macchiatobin or a rock5itx would make excellent boards for this without being server-grade, and would easily compete in terms of performance and reliability with a number of NAS devices people usually buy from the common vendors, which also make them from the same SoCs found on these SBCs (or even lower end ones with unreliable optimizations brought by dirty BSP) and always without ECC anyway…
> But my understanding is that FreeNAS was always made to reuse old or limited hardware.
Well, the company behind FreeNAS/TrueNAS (iXsystems) sells storage servers for two whole decades now and they claim TrueNAS being ‘used by a majority of Fortune 500 companies’.
OpenMediaVault would more fit the specific role you were talking about.
Yes, presented like this it obviously makes a lot of sense 🙂
Also thanks for the link, I had a great laugh. Yes, ECC is very useful, but the scrubbing part is totally unrelated to that! The main problem happens once data are loaded into application memory and bits get flipped there before being written back to disk (e.g. mmap()ed page that’s partially modified and gets written back from the page cache to the device once dirty). In this case no FS mechanism will be able to detect anything and that’s precisely where ECC helps. But I agree with the article that scrubbing will not make things worse and that bit flips at this stage will just be detected as errors and that’s all.
The real problem back at that time was storage (controllers) not properly implementing ‘write barrier semantics’ (what should be written to disk has realy be written to disk in a specific order) and this affects not just ‘checksumming’ filesystems like ZFS or btrfs but also already journaled ext4.
Users are clueless and want to use the latest and greatest filesystems on the storage they already have (even if crappy). By talking them into ECC RAM they ‘understand’ that they need to get server grade hardware and the typical data corruption/loss issues were less likely to happen.
> By talking them into ECC RAM they ‘understand’ that they need to get server grade hardware
Let’s see how long this stands with entry-level hardware now bringing IBECC 🙂
Hi, I’m the developer of this port. I anticipated that the 8 GB minimum memory requirement would have been the bigger pain point for low-end SBCs, but anyway…
Consider the perspective of what platform TrueNAS is intended to run on. In the amd64 world, you’re going to be hard pressed to find any system that will run TrueNAS well with less than 64 GB of storage. So they can afford to be wasteful of storage in order to cram in more features with no downside.
I do find it unfortunate that many of the Arm SBCs aren’t suitable to run TrueNAS for one reason or another. But there are other options available that serve the low-end market better.
Also, I’ll note that the size on disk after installation is significantly less than 16 GB. So your 1024x figure might be an apple to oranges comparison. It might actually be more like 512x, which is still a large discrepancy.
Hi Joel,
> I do find it unfortunate that many of the Arm SBCs aren’t suitable to run TrueNAS for one reason or another. But there are other options available that serve the low-end market better.
I’m seeing it the other way around: TrueNAS is not suitable for many SBCs.
The real problem here is that as soon as the storage requirement becomes high, it cannot use the default on-board devices anymore, meaning that it requires to condemn one extension that could have been used for the data storage. For example, if you take a 4-port M.2 adapter and are forced to have large storage for the system, then you need to reserve one for the OS instead of using the default on-board storage. That’s really sad, particularly when you consider some of the very well-suited devices like mcbin and rock5itx which both come with 8GB eMMC on board.
I know it’s not your fault, I’ve read your message saying you’ve repackaged the same OS as the original one. But still I can’t imagine what could be installed by default on this NAS OS to occupy even 8GB. That corresponds to a full distro with development packages and all services, while it’s only a NAS. It’s a bit disappointing.
> TrueNAS is not suitable for many SBCs.
For the simple reason that it will kill the system storage (your 8GB eMMC) in no time due to constant writing with unnecessarily high Write Amplification, see for example https://forums.truenas.com/t/unexpectedly-high-ssd-wear/5181/2
In OpenMediaVault there has been the flashmemory plugin added that redirects those constant writes into RAM and syncs it to disk only every now and then with a Write Amplification of close to 1.
They seem to be talking about the data storage, not the system storage. That’s not super clear to be honest. Because the system storage should be read-only and only be written to if it ever supports packages. Well, we’re nitpicking around design rules regarding a product that already exists anyway. And I don’t need to be convinced, I’m sure I will not use it.
> They seem to be talking about the data storage, not the system storage.
Both but I was more focusing on this https://ixsystems.atlassian.net/browse/NAS-129237
TrueNAS will log cheap flash storage used as boot drive in no time to death due to high Write Amplification caused by constant small writes. That’s one reason it will suck on an average SBC, the other most probably is performance at least judging by the amount/type of optimizations that went into OMV to fix this stuff.
That’s cpufreq settings that work fine on x86 and ARM servers but destroy performance on the average SBC, that’s on big.LITTLE systems (missing) SMP/IRQ affinity and related stuff like RPS and so on…
Ah got it! Indeed, logging to eMMC is no good. Better log to RAM and rotate daily.
Your commit message wrt ‘TrueNAS binaries’ reads: ‘sas2ircu, sas3ircu, sas2flash, sas3flash, storcli, and storcli2 are closed source and unavailable for aarch64.’
Googled only for the two last which can be found here for even more exotic platforms than aarch64: https://www.broadcom.com/support/download-search?dk=storcli
Jeff installed TrueNAS on a Raspberry Pi 5: https://www.jeffgeerling.com/blog/2025/how-install-truenas-on-raspberry-pi
The good news is that it can be installed after installing UEFI firmware, but a few things are not working yet:
The last one means the user would need to add a USB-to-Ethernet adapter for now.