Migrate from TrueNAS Core to vanilla FreeBSD

[Coffee and Cigarettes]

Hi there,

I am currently running TrueNAS Core 13.0-U6.8 on a server, the last version of TrueNAS with FreeBSD.
Since this project is going in a direction I don't like, I decided to migrate my server to vanilla FreeBSD.
The current setup is not very fancy, basically a file server exposing some SMB shares and 3 jails.
I have a rough plan in my head on how to migrate and I also have some questions. Would be great if you can give me your opinion and answer some of my questions.

The server is running headless with a system SSD and 4 data HDDs. The SSD holds the TrueNAS installation, the 4 HDDs are configured as one RAID-Z2 pool with a bunch of datasets.

Migration plan:
- export the pool from TrueNAS
- boot FreeBSD ISO, wipe SSD, install FreeBSD 15 RELEASE, use shiny new pkgbase
- enable and configure SSH
- update all packages
- import the pool
- create users and groups with same UIDs as in TrueNAS
- create SMB shares with these users and groups
- configure mail alerting
- create periodic snapshots and scrubbing tasks
- create periodic SMART tests
- create jails as needed and configure them
- install Webmin/Sylve to have a fancy overview and monitoring graphs
- look into boot environments before upgrading to the next release

Questions:
- Does this look reasonable? Anything to add?
- My jails are on the data disks. Any way to update and re-use them? (They were created with iocage)
- Is there any way to have the FreeBSD install in a boot environment besides TrueNAS? Like a dual boot solution?
- I have a bunch of "legacy" mount points when doing

zfs list

. I guess these come from some former TrueNAS upgrades. I assume these are safe to delete before I switch over?

zfs list
NAME                                                    USED  AVAIL     REFER  MOUNTPOINT
freenas-boot                                           4.89G   220G       23K  none
freenas-boot/ROOT                                      4.87G   220G       23K  none
freenas-boot/ROOT/13.0-U4                               178K   220G     1.29G  /
freenas-boot/ROOT/13.0-U6.2                             176K   220G     1.29G  /
freenas-boot/ROOT/13.0-U6.8                            4.87G   220G     1.28G  /
freenas-boot/ROOT/Initial-Install                         1K   220G     1.00G  legacy
freenas-boot/ROOT/default                               223K   220G     1.00G  legacy
tank                                                   14.7T  20.3T      378K  /mnt/tank
tank/.system                                            249M  20.3T      140K  legacy
tank/.system/configs-6c934beb66de482e8faef2d3b30acc82   211M  20.3T      211M  legacy
tank/.system/cores                                      128K  1024M      128K  legacy
tank/.system/rrd-6c934beb66de482e8faef2d3b30acc82      34.7M  20.3T     34.7M  legacy
tank/.system/samba4                                    1.71M  20.3T      436K  legacy
tank/.system/services                                   140K  20.3T      140K  legacy
tank/.system/syslog-6c934beb66de482e8faef2d3b30acc82    343K  20.3T      343K  legacy
tank/.system/webui                                      128K  20.3T      128K  legacy
[...]

Thanks!

 

[Mjölnir]

Since the system SDD is ZFS, I would not wipe it's content. Keep it, so you can switch back if s/th goes wrong, and if everything goes well you can comfortably access the old configuration. Install to new datasets and set the new ROOT/default as bootfs of the zpool. DO NOT UPGRADE the zpool to a new version if you're informed or asked about that. Wait until you're really sure that your new plain vanilla FBSD runs ok like you want it and you will not switch back to the old system, 100%. Then and only then you can upgrade the pool, which unlocks some new features.

You can either take a snapshot of your old system's datasets, then wipe the contents (<code>rm -fr</code>) and reuse them for the new system. Or rename the old system's datasets (<code>zfs rename</code>) and create the new ones from the installer shell or a shell on the old system. You should create a <code>zpool checkpoint</code> of the zpool on your system ssd prior to installation. Inform yourself which datasets the installer expects.

BIG FAT WARNING: DO NOT USE EDONR as checksum on a zpool that you want to boot from. You can not boot from a zpool with edonr active in any dataset, volume or snapshot. It's enough that only one single block of ANY dataset, volume or snapshot of that zpool has this shiny new checksum, then this will make the pool unbootable, even if the bootfs does not have edonr checksum in any block.

2nd, I would not switch to FBSD-15 yet, unless you're very curious and like to help with writing qualified bug reports or love the pain (some do ). Better stay with 14.4 for now, and switch to 15.2 when it's ready.

 

[Alain De Vos]

You have place for a freebsd-zfs pool ?
I so , create one & install FreeBSD 15.0
Then create datasets as needed.
And use clone to copy over the files.
I everything works fine, zpool destroy TRUENAS & delete partition.

 

[Mjölnir]

You have place for a freebsd-zfs pool ?
I so , create one & install FreeBSD 15.0
Then create datasets as needed.
And use clone to copy over the files.
I everything works fine, zpool destroy TRUENAS & delete partition.

if the old zpool of TrueNAS already occupies the whole ssd, there is no space left IIUC. AFAIK you can not shrink a zpool, right? If I'm wrong, yes that would be nice, then you can create a 2nd zpool for the new system beneath the zpool of the old system.

And as long I see reports about weird problems with FBSD-15, IMHO you should not advise to go to FBSD-15 ATM (March 2026) until you're sure that the receipient is an experienced FBSD wizzard who is likely able to solve most problems him/herself.

 

[Mjölnir]

On webmin: I read in the XigmaNAS forum from a guy who switched from a Linux-based NAS to a plain vanilla FBSD NAS that he had to spend some time disabling some webmin modules that did not work in adequate quality, and (naturally) to delete all those fancy goodies that he wouldn't need anyway. But IIUC that was worth it.

 

[mer]

And as long I see reports about weird problems with FBSD-15, IMHO you should not advise to go to FBSD-15 ATM (March 2026) until you're sure that the receipient is an experienced FBSD wizzard who is likely able to solve most problems him/herself.

What weird problems? I've been running 15.0-RELEASE on 2 different systems as daily drivers without issues. One is a simple single device system running ZFS the other mirrored pairs for "OS pool" and separate data/home directory pool

OP:
Do you have physical space to add another SSD for a boot device?
If so here's what I've done in the past upgrading systems (no not running TrueNAS, but FreeBSD systems with ZFS pools).
zpool export the "data pool" and power down
add a new device for the "os", unplug the current boot/os SSD (purely for safety)
power up and install FreeBSD-15.0-RELEASE on the new device, verify the basic installation is correct
import the data pool and continue configuring

Basically what you posted, just on a new device.
Why?
It gets you a new device (not sure how long the previous SSD was running for) and lets you
preserve a working configuration.
you can always hook the old device back up and import to an altroot. That lets you simply copy files instead of hoping you wrote everything down.

 

[Mjölnir]

What weird problems? I've been running 15.0-RELEASE on 2 different systems as daily drivers without issues. One is a simple single device system running ZFS the other mirrored pairs for "OS pool" and separate data/home directory pool

I dont find the thread quicky now. From December '25. Yes, of course there are 100's of systems running FBSD-15.0 flawlessly! But OTOH please keep in mind: your 2 systems is what the statisticians call "anecdotal" and it's pretty normal that the 1st 1-2 releases of a new major branch have some problems, at least on some configurations, i.e. hardware. Remember that there are more hardware combinations possible than atoms in the universe and only a few 100 can be tested... It's normal that problems come up. Experience tells that the safe way is to go to the .2-RELEASE and before that you can help with qualified bug reports, if you have additional hardware and/or enough time resources to do that.

 

[Mjölnir]

And yes of course if you have a 2nd SSD you can put the SSD with the old system in a safe and install onto a new SSD. But if you dont have another SSD, it's best NOT to destroy the zpool on it, but keep it, don't upgrade the zpool version (yet), keep the datasets of your previous OS (rename or at least snapshot) and install FBSD on the SAME zpool, either new datasets or reuse the ones you have snapshot'ed. "zpool checkpoint" is your life insurance, both on the system zpool and the data zpool.

 

[vermaden]

Hi there,

I am currently running TrueNAS Core 13.0-U6.8 on a server, the last version of TrueNAS with FreeBSD.
Since this project is going in a direction I don't like, I decided to migrate my server to vanilla FreeBSD.

As vault.io seems to take longer for its next update/release - you may as well migrate to SYLVE - https://github.com/AlchemillaHQ/Sylve - nice web interface and ZFS pool management.

 

[Mjölnir]

I dont find the thread quicky now. From December '25. [...]

What weird problems? I've been running 15.0-RELEASE on 2 different systems as daily drivers without issues. One is a simple single device system running ZFS the other mirrored pairs for "OS pool" and separate data/home directory pool

This is the one I meant: https://forums.freebsd.org/threads/14-3-release-p6-to-15-0-release-ipfw-issues.100603/post-730467 and here's another one https://forums.freebsd.org/threads/freebsd-15-0-release-issues-strange-issues.102027/post-749795

 

[Coffee and Cigarettes]

Since the system SDD is ZFS, I would not wipe it's content. Keep it, so you can switch back if s/th goes wrong, and if everything goes well you can comfortably access the old configuration. Install to new datasets and set the new ROOT/default as bootfs of the zpool. DO NOT UPGRADE the zpool to a new version if you're informed or asked about that. Wait until you're really sure that your new plain vanilla FBSD runs ok like you want it and you will not switch back to the old system, 100%. Then and only then you can upgrade the pool, which unlocks some new features.

Yeah, I am still thinking if I want to keep the FreeNAS installation for some time if something goes wrong. As I wrote the server config is not that complicated. Currently I am reading through the config and write ansible tasks for the new installation which I will try in a VM before switching...I am aware of the zpool version issue.

You can either take a snapshot of your old system's datasets, then wipe the contents (<code>rm -fr</code>) and reuse them for the new system.

How would that work? If I wipe the content the snapshots will also be wiped?

Or rename the old system's datasets (<code>zfs rename</code>) and create the new ones from the installer shell or a shell on the old system. You should create a <code>zpool checkpoint</code> of the zpool on your system ssd prior to installation. Inform yourself which datasets the installer expects.

Same problem? The installer wipes the zpool and creates a new one so the checkpoint is gone?
I was also researching if it would be possible to create a new boot environment and install FreeBSD there but it seems rather complicated and error prone. So not sure if I want to try it.

You have place for a freebsd-zfs pool ?
I so , create one & install FreeBSD 15.0
Then create datasets as needed.
And use clone to copy over the files.
I everything works fine, zpool destroy TRUENAS & delete partition.

OP:
Do you have physical space to add another SSD for a boot device?
If so here's what I've done in the past upgrading systems (no not running TrueNAS, but FreeBSD systems with ZFS pools).
zpool export the "data pool" and power down
add a new device for the "os", unplug the current boot/os SSD (purely for safety)
power up and install FreeBSD-15.0-RELEASE on the new device, verify the basic installation is correct
import the data pool and continue configuring

Basically what you posted, just on a new device.
Why?
It gets you a new device (not sure how long the previous SSD was running for) and lets you
preserve a working configuration.
you can always hook the old device back up and import to an altroot. That lets you simply copy files instead of hoping you wrote everything down.

The SSD from which the system boots is occupied by the freenas-boot zpool. There is space left but I can't shrink a ZFS pool as far as I know. I could buy a new SSD and but meh...

As vault.io seems to take longer for its next update/release - you may as well migrate to SYLVE - https://github.com/AlchemillaHQ/Sylve - nice web interface and ZFS pool management.

Yes, that looks nice. I am waiting for an official pkg.

Thanks for all your answers and ideas so far.

 

[Alain De Vos]

sorry occupied, is bad language. Not accepted by guidelines, please be specific. And have nice day.

 

[q-pa]

As vault.io seems to take longer for its next update/release - you may as well migrate to SYLVE - https://github.com/AlchemillaHQ/Sylve - nice web interface and ZFS pool management.

Can you define the dataset for your jails in Sylve? E.g., you always managed your jails with bastille and then switch to Sylve, can the jails stay in the bastille dataset?

 

[vermaden]

I did not yet had time to try Sylve on my hosts ... but with ZFS features such as 'zfs set mountpoint=(...)' or 'zfs rename ...' to move dataset into other place - I do not see any issues here.

 

[Mjölnir]

I wrote: "snapshot the ROOT/default dataset and then you wipe out it's contents with rm -fr /"

How would that work? If I wipe the content the snapshots will also be wiped?

No, a snapshot is read-only forever. It can never be set set r/w, but you clone it to produce a writable dataset.

Same problem? The installer wipes the zpool and creates a new one so the checkpoint is gone?

IMHO you should choose the menu entry "open a shell" to create the datasets (is that "expert mode"?). You must mount these under /mnt, then exit the shell. Inform yourself which layout is the default, i.e. which datasets the installer expects and which ZFS properties it sets. You may want to set a non-default compression and/or checksum, e.g. I have zstd as default for the zpool, zstd-4 for read-mostly datasets and zstd-fast for pool/var and other datasets where I expect or want more speed, and I hope that skein is faster than the default checksum. DO NOT USE EDONR, it would make the zpool unbootable, even one block with this checksum, regardless if it's in the bootfs or not.

I was also researching if it would be possible to create a new boot environment and install FreeBSD there but it seems rather complicated and error prone. So not sure if I want to try it.

No it's not complicated at all, the opposite is true: it's kinderleicht. RTFM bectl(8). But this is intended to creates a new BE from a snapshot of the current BE (the system currently running), i.e. for an update like from 14.3 to 14.4 or from 14.4 to 15.0. You can easily create a new BE just by renaming ROOT/default to let's say ROOT/freenas and create a new ROOT/default. BEs are those dataset under ROOT, that's all IIUC. And you set the zpool property bootfs which BE to boot, easy going. You will understand/get familiar quickly once you've done it a few times.

The SSD from which the system boots is occupied by the freenas-boot zpool. There is space left but I can't shrink a ZFS pool as far as I know. I could buy a new SSD and but meh...

That's not neccessary. If you have enough space, IMHO safest is to just rename ROOT/default, eg. to ROOT/freenas (optionally append the version freenas-13) Then create a new ROOT/default and other datasets the installer expects and install FreeBSD (by mounting them under /mnt when you booted the install image)

 

[jmpalacios]

Hi there,

I am currently running TrueNAS Core 13.0-U6.8 on a server, the last version of TrueNAS with FreeBSD.
Since this project is going in a direction I don't like, I decided to migrate my server to vanilla FreeBSD.
The current setup is not very fancy, basically a file server exposing some SMB shares and 3 jails.
I have a rough plan in my head on how to migrate and I also have some questions. Would be great if you can give me your opinion and answer some of my questions.

The server is running headless with a system SSD and 4 data HDDs. The SSD holds the TrueNAS installation, the 4 HDDs are configured as one RAID-Z2 pool with a bunch of datasets.

Migration plan:
- export the pool from TrueNAS
- boot FreeBSD ISO, wipe SSD, install FreeBSD 15 RELEASE, use shiny new pkgbase
- enable and configure SSH
- update all packages
- import the pool
- create users and groups with same UIDs as in TrueNAS
- create SMB shares with these users and groups
- configure mail alerting
- create periodic snapshots and scrubbing tasks
- create periodic SMART tests
- create jails as needed and configure them
- install Webmin/Sylve to have a fancy overview and monitoring graphs
- look into boot environments before upgrading to the next release

Questions:
- Does this look reasonable? Anything to add?
- My jails are on the data disks. Any way to update and re-use them? (They were created with iocage)
- Is there any way to have the FreeBSD install in a boot environment besides TrueNAS? Like a dual boot solution?
- I have a bunch of "legacy" mount points when doing

zfs list

. I guess these come from some former TrueNAS upgrades. I assume these are safe to delete before I switch over?

zfs list
NAME                                                    USED  AVAIL     REFER  MOUNTPOINT
freenas-boot                                           4.89G   220G       23K  none
freenas-boot/ROOT                                      4.87G   220G       23K  none
freenas-boot/ROOT/13.0-U4                               178K   220G     1.29G  /
freenas-boot/ROOT/13.0-U6.2                             176K   220G     1.29G  /
freenas-boot/ROOT/13.0-U6.8                            4.87G   220G     1.28G  /
freenas-boot/ROOT/Initial-Install                         1K   220G     1.00G  legacy
freenas-boot/ROOT/default                               223K   220G     1.00G  legacy
tank                                                   14.7T  20.3T      378K  /mnt/tank
tank/.system                                            249M  20.3T      140K  legacy
tank/.system/configs-6c934beb66de482e8faef2d3b30acc82   211M  20.3T      211M  legacy
tank/.system/cores                                      128K  1024M      128K  legacy
tank/.system/rrd-6c934beb66de482e8faef2d3b30acc82      34.7M  20.3T     34.7M  legacy
tank/.system/samba4                                    1.71M  20.3T      436K  legacy
tank/.system/services                                   140K  20.3T      140K  legacy
tank/.system/syslog-6c934beb66de482e8faef2d3b30acc82    343K  20.3T      343K  legacy
tank/.system/webui                                      128K  20.3T      128K  legacy
[...]

Thanks!

I'm exactly on the same boat, a far from trivial TrueNAS CORE rig, hosting a pfSense router VM (with PCI passthrough for the NICs), VMs for other purposes, and a whole bunch of iocage jails, and I'm looking to migrate all that to either Sylve or, simply, vanilla FreeBSD + Ansible playbook(s)/role(s).

I'm trying to minimize the ginormous amount of work I have to do to complete such a migration by first migrating all my jails to Bastille templates (only three more to go!), which I keep version controlled and deploy within purpose-specific VMs.

Those VMs, once my current Bastille-centered work is done, will be fully managed by Ansible. And, needless to say, the code for that will also be kept in version control. Further, the VMs operate on top of zvols that live on my data pools, so once I import those into the new host OS, the VMs should be able to boot up just fine (this last point also applies to the root drive of my pfSense VM).

All in all, the main idea here is to first move as much workload as possible away from TrueNAS directly and into something that's 1) more portable (e.g. those zvols that live on my data pools), and 2) scriptable & "automatable" (e.g. the Ansible playbooks/roles + Bastille jail templates).

With this infrastructure-as-code approach I'm aiming to make 100% of my workloads fully reproducible and, therefore, disposable. The data that these jails generate either live directly on top of NFS shares that are exported by TrueNAS (from the data pools, of course) and then nullfs-mounted into the jails (e.g. GitLab repos, build artifacts, etc.), or are periodically backed up to applicable directories within applicable NFS shares also exported by TrueNAS and nullfs-mounted into the jails (e.g. MySQL & PostgreSQL & SQLite fully-contained snapshots, etc.).

An alternative to the above is virtio-p9fs sharing between the host and the VMs, which would definitely simplify the setup, but I didn't give too much thought to this originally given that TrueNAS is FreeBSD 13.3, and at the time of going with NFS shares I understood that virtio-p9fs sharing required a FreeBSD 14.3 host, at least.

Once this work is done, the items that'll remain to fully migrate away from TrueNAS will be, some of which you already identified, reproducing on FreeBSD and/or Sylve, in no particular order:

• Boot-time configurations (e.g. kernel modules, system tunables, interface configurations, etc.).
• Accounts & groups.
• Samba shares.
• NFS shares.
• Snapshot & replication policies (configurations, schedules, retention, etc.).
• Cron jobs.
• Monitoring and alerting.
• Some VM admin facility, e.g. vm(8).
• Surely something else I'm missing.

Most definitely a LOT of work, but also a lot more manageable than trying to migrate everything without the heavy infrastructure-as-code & automation focus described above.

As for installing FreeBSD on an existing pool, I wish the FreeBSD installer were more friendly to this scenario… and perhaps it is, and I'm still not sharp-eyed enough to find and click the right buttons, so the only way I've found to do that is entering manual partitioning mode and rolling up my sleeves.

But a silver lining that you'll find in this case is that an important part of the work is already done for you. You won't need to create the pool from scratch, as it's already there, and you definitely won't need to partition the drive, nor create the boot partition (BIOS or UEFI), copy the boot code into the latter, nor any of that, because it's all already there on your SSD (as revealed by gpart show -p $bootDrive). I mean, think about it: if all that's not already there, then how are you booting TrueNAS from this drive/pool?

What you will need to do, as suggested by Mjölnir, is:

1. Rename the current freenas-boot/ROOT/default dataset to whatever you want, and create a new freenas-boot/ROOT/default replacement one.
2. Adjust the bootfs property on the pool to point to this new dataset.
3. Create the other datasets that the FreeBSD installer expects, with their very specific settings, as revealed at the very top of a zpool history query on an existing off-the-shelf boot pool.
4. Mount freenas-boot/ROOT/default on /mnt.
5. Follow the remainder of the installer's instructions for the /etc/fstab file.
6. Exit the shell and continue with the installation.
7. Profit.

If anything goes south, you can always reboot into the installer, import the boot pool and adjust the bootfs property accordingly, and reboot back into TrueNAS.

Lastly, those "legacy" datasets that you have on your boot pool, underneath tank/.system, are TrueNAS' replacements for the datasets I mention above in point No. 3. The reason, if I recall correctly, why FreeNAS back in the day decided for this approach is that, thanks to a lot of crappy advice out there, a lot of people were installing the OS on cheap & low quality USB thumb drives that wore down very quickly with the amount of writes the system logs produced, and then complaining about unbootable systems. The single, containing .system dataset, instead, paired with the "legacy" mounting option, enabled iXsystems to create the necessary machinery to make this "System dataset" portable across pools (via snapshotting & replication under the hood, of course), which would then allow users to host it on the almost always much more durable data drives you typically find in a NAS appliance by simply choosing the desired pool via dropdown in the web UI.

Once you install vanilla FreeBSD, with the datasets described in 3, and are comfortable with your setup, it should be safe to "archive", and eventually destroy, the .system dataset.

There's definitely a LOT to explore in such a gargantuan endeavor, but this should be a good start, and I hope it helps you get started!