BSDnas¶
A community fork that continues TrueNAS CORE on current FreeBSD.
TrueNAS CORE stopped at 13.3, on FreeBSD 13.3 — a release that has since been
removed from the FreeBSD mirrors. BSDnas moves that system onto FreeBSD
stable/15 and keeps it there: new FreeBSD releases, security advisories and
OpenZFS versions are tracked continuously rather than in one heroic jump every
few years.
Anyone can build this image themselves, from the same open code. The whole system — FreeBSD base, middleware, web interface and the build scripts — comes from the project's own repositories at github.com/bsdnas, with the commands written out on the Building from source page. That is not an aspiration: the build that settled the point took 14 minutes, failed on no port, and produced the 1.1 GB ISO and the 923 MB update archive the project ships. The ports tree is deliberately not forked — the quarterly branch comes straight from FreeBSD.
And this fork is free to be built, which is the sharper difference.
Published source is not by itself permission to build an image and hand it to
someone else. In the TrueNAS CORE tree, 46 files carried LICENSE.IX — the
TrueNAS Enterprise licence, which forbids derivative works outright — and the
update machinery relied on signing keys and certificates belonging to
iXsystems. Reading the code was never the obstacle; building your own system
out of it and giving it to somebody else was. Here that is closed: those 46
files are gone, along with the parts that were proprietary in substance without
being marked (fenced, hactl, firmware_update.py, ix-haready,
proactive_support.py), and the middleware still works without them — checked
end to end through its own API after the removal, not assumed. iX's
update-signing keys and certificates (iX-CA.pem, freenas-update.pem,
Production.pem, Nightlies.pem) were deleted, and the project signs with a
key of its own: ed25519, only the public half inside the image, and a manifest
whose signature decides whether an update runs at all. On 5 October 2026 the
last of iX left the build itself — the publisher string that stamped
"iXsystems Inc." into every ISO, the project and support addresses the build
wrote into /etc/avatar.conf on every installed machine, and the address build
failures were mailed to.
What this does not claim is a bit-for-bit identical image on a second build: nobody has measured that. The claim is the one an outsider can check for themselves — published sources, published scripts, and an image that comes out of them.
Read this before you install anything
This is an early project. Everything described here has been measured on a test machine, and nothing has been measured anywhere else. Do not put your only copy of anything on it.
The first build is available on the Download page.
What actually works¶
Verified on a test stand, not claimed from theory:
| Builds from published source, by anyone | yes, on FreeBSD stable/15, entirely from the project's own repositories |
| Installs from ISO | yes |
| Upgrades an existing TrueNAS CORE 13.3 install | yes, config preserved |
| Pools created by OpenZFS 2.2 | import and work on 2.4.3 |
| SMB shares, users, passwords from 13.3 | preserved |
| iocage jails with 13.3 userland | run on the FreeBSD 15 kernel |
| OCI containers, FreeBSD and Linux images | run from the command line |
| Updating without boot media | works, through the project's update train |
| System and data on the same disks | yes — no separate boot device or USB stick |
| Boot pool mirror | three disks by default, run across six |
| Installing beside someone else's system | into the free space of the disks, existing partitions untouched — one layout: a foreign GPT table of FreeBSD/ZFS partitions, BIOS boot. Caveats below |
| An upgrade that cannot find a system to upgrade | refuses and stops, does not wipe |
| Build scripts | public, in the same repository the images are built from |
Swap needs no disk or partition of its own: it is cut from the same disks, at the point the data pool is created. That one is read from the code and from what an install leaves on the disks — not from a load test. How swap behaves while the same disks are serving a share has not been measured, so it is not in the table above.
A single upgrade run moves the system from FreeBSD 13.3 to stable/15, OpenZFS 2.2 to 2.4.3, Samba 4.20 to 4.23, and the ports Python from 3.9 to 3.11. On the test stand it takes about fifteen minutes.
See Upgrading for the procedure and the caveats — particularly
the one about zpool upgrade, which is worth reading before you run it.
How this is tested¶
On a physical machine, not only in a virtual one. The stand is an ordinary desktop-class box: six SATA disks, an AMD Phenom II, an onboard Realtek network adapter, a BIOS rather than UEFI. It is installed over the network and watched through an IP KVM, and its disks are wiped and repartitioned several times a day.
This is not a detail of process. The faults that cost the most days here are exactly the ones a hypervisor never shows: a BIOS that refuses to describe one disk and so hides every disk behind it from the boot loader; a boot loader that runs out of low memory when the PXE stack is resident; a network card whose firmware drops every thirteenth reply and turns a one-minute boot into an hour. None of those exist in a virtual machine, and all of them exist in the machines people actually own.
The limit of this is worth stating as plainly as the rest: it is one machine. SAS controllers, UEFI boot and disk counts beyond six have not been exercised on metal.
What does not work yet¶
Honesty is cheaper than support tickets:
- The published image is a development build — see Download. It is signed, but verified on one virtual machine only.
- The SSH service does not start by itself after an upgrade; enable it again.
- The iocage plugin index is no longer maintained upstream, so plugins must come from your own index or be installed by hand.
- Hardware RAID utilities (
arcconf,megacli,tw_cli) are not included: their vendors withdrew the distribution files. On a ZFS system hardware RAID is inadvisable anyway. - VMware and Xen guest additions are currently absent — those ports do not compile on FreeBSD 15 with the current compiler.
- Containers run, but only from the command line — the web interface knows nothing about them.
- Update manifests are signed now, and the signature decides whether an
update happens at all: no key in the image, or a signature that does not
verify, and the update refuses to start rather than carrying on. The key is
ed25519, ships inside the image, and expires on 11 August 2029.
What is not signed is the repository packages themselves — pkg is
configured with
signature_type: none. Their integrity rests on the transport, so the updater refuses any repository that is not served over HTTPS. Signing the repositories is work still to be done, and until it is, a signed manifest proves which repository to use and nothing about the bytes that come out of it. - Upgrading from TrueNAS SCALE is not supported. The installer recognises that the system on the disks is not one of ours and stops. The data pool is readable: a pool created by OpenZFS on Linux imports on this FreeBSD with every active feature supported, which was checked before the refusal was accepted as the right answer.
- Upgrading from FreeNAS 9.x on UFS is not supported either. The installer did not recognise it as a system of ours and stopped; we cannot yet say whether that was the UFS filesystem or the fact that this install had never been booted and so had no configuration database to find.
- In both of those cases the system can still be installed into the free
space of the same disks, leaving the existing partitions and the data where
they are — but nothing is carried over from the old configuration, and the
path is narrower than it sounds:
- one layout has been through a run on real hardware: a foreign GPT table of FreeBSD/ZFS partitions, the machine booted in BIOS mode;
- a Linux layout (ext4 beside an OpenZFS pool) has not been tried, so the SCALE case above is not covered by that run;
- MBR is not supported at all. The installer stops and says the layout needs GPT. Old FreeNAS installs are exactly the ones likely to carry MBR;
- UEFI is refused on purpose. Installing beside an existing system does not create an EFI system partition of its own, and writing our loader into the existing one would overwrite somebody else's;
- going back does not work. The previous system stayed on its disk with its partitions untouched, but the machine would not boot into it again afterwards. We have not separated by experiment whether that follows from the install or from that particular old install, so treat this as one-way until we have.
Why this exists¶
A fork rots when nobody moves it forward. The gap between TrueNAS CORE 13.3 and current FreeBSD did not open because of any hard technical problem — it opened because for a year nobody rebased the patches.
So the project is built around that failure mode. The FreeBSD patch set is carried as a rebased series rather than a merge history, an upstream watcher reports every week what has moved (FreeBSD base, security advisories, the quarterly ports branch, OpenZFS), and every claim on this site comes with the measurement behind it.
Not affiliated with iXsystems¶
BSDnas is an independent fork. It is not produced, endorsed or supported by iXsystems, Inc. TrueNAS is their trademark. The middleware this project builds on is LGPL-3.0; files covered by the TrueNAS Enterprise licence were removed from the fork at the outset.