Migrating from TrueNAS to NixOS without losing data after the build-system rug pull | Bas Nijholt<br>Search
Migrating from TrueNAS to NixOS without losing data after the build-system rug pull<br>How I used an AI agent with root-capable SSH, strict no-change instructions, disko, and a VM rehearsal to replace my last appliance OS without letting it near my ZFS data pools<br>Bas Nijholt<br>Published on 2026-06-28
Last updated on 2026-06-29
18 min read
Technology, DevOps, Level:intermediate
TrueNAS was the last non-NixOS machine in my home lab.<br>I kept postponing it for a simpler reason: moving something with ~100 TiB of data feels scary.<br>My NAS holds the big ZFS pools.<br>It has the SMB shares, NFS exports, snapshots, replication tasks, encrypted datasets, Incus state, Docker workloads, and all the boring-but-important health checks that are easy to take for granted until something fails.<br>I had already migrated most of my machines from Proxmox to NixOS with Incus, as I wrote about in I’ve gone full Nix: Proxmox to NixOS + Incus.<br>That migration made me increasingly intolerant of appliance-style infrastructure.<br>If the important state lives in a database behind a web UI, I cannot review it in a pull request.<br>If I change something while debugging, I cannot guarantee the change made it back into the source of truth.<br>And if I let an AI agent help me, imperative systems become even more uncomfortable: an agent can run a hundred commands, succeed, and leave behind a system that nobody can reproduce.<br>For the NAS specifically, that basically meant I did not dare touch the machine with an AI agent at all.<br>NixOS is different.<br>The diff is the state.<br>If an agent changes my infrastructure, I can review the patch.<br>If the change is wrong, I can reject it.<br>If it works, I can commit it.<br>TrueNAS was the last holdout.<br>It had been itching for a while.<br>Then the build-system rug pull made the decision easy.<br>Table of ContentsThe itch before the last straw #<br>The build-system change was not the first thing that bothered me.<br>It was just the last straw.<br>The deeper problem was that my TrueNAS setup had slowly become complicated in exactly the way I dislike.<br>I had clicked many buttons in the UI over time:<br>SMB shares<br>NFS exports<br>snapshot tasks<br>replication tasks<br>users and groups<br>encrypted datasets<br>apps and containers<br>Incus storage<br>old Jailmaker/systemd-nspawn state<br>alerting<br>UPS settings<br>TrueNAS can export and import its configuration.<br>That is genuinely useful.<br>But a database export is not the same thing as a configuration I can comfortably review.<br>When I look at a TrueNAS backup, it is not obvious to me which settings I intentionally changed, which settings are defaults, which settings are historical leftovers, and which settings only exist because I clicked something while debugging two years ago.<br>One concrete example was NFS.<br>I needed the crossmnt export option so child datasets would show up correctly inside the Docker container host, but TrueNAS did not expose that option in the UI.<br>So I had a periodic root cron job patching /etc/exports after TrueNAS generated it.<br>It worked, but it was exactly the kind of small appliance hack that made me uneasy: partly outside the UI, partly outside the exported configuration, and very easy to forget during a migration.<br>In NixOS, that behavior is just part of the export line.<br>That is the exact discomfort that pushed me away from Proxmox.<br>I do not want to remember what I clicked.<br>I want the system to remember it as code.<br>The second itch was virtualization.<br>My TrueNAS container story had already gone through one migration.<br>For a while I used Jailmaker, which is a clever script around systemd-nspawn for running Linux “jails” on TrueNAS SCALE.<br>It worked well enough for what I needed at the time: a Debian environment where I could run Docker workloads close to the data.<br>But it also reinforced the feeling that I was building a fairly custom server on top of an appliance OS.<br>TrueNAS 25.04 “Fangtooth” introduced experimental Containers, named Instances in the early 25.04 releases, and the 25.04.1 announcement explicitly described Instances as being based on Incus, supporting both VMs and LXCs.<br>That was interesting to me because the older TrueNAS VM system was libvirt-based, while Incus felt like a more coherent container/VM story.<br>Then the TrueNAS virtualization plan for 25.04.2 explained that Fangtooth’s Instances feature caused challenges for some users and that 25.04.2 would re-enable the older Virtualization VM path alongside Instances.<br>The 25.04.2 release announcement made that split official: Virtual Machines came back, while VMs created through the earlier Instances feature continued to appear under Containers.<br>For many people that churn was probably annoying.<br>For me it was especially ironic.<br>I had migrated from Jailmaker’s systemd-nspawn setup to Incus, read up on Incus, got excited about it, started using it, and then became genuinely happy with it when I migrated from...