TrueNAS SCALE 26 Beta Changes for Your Proxmox Homelab

TrueNAS SCALE 26 has entered beta with OpenZFS 2.4 and native LXC container support, and for homelabs that run Proxmox VE for compute against a TrueNAS storage node, the release touches the two things that actually matter: how your pools import and how your shares behave. The short version is that OpenZFS 2.4 bumps the pool version, which can leave an older Proxmox kernel module unable to import a pool you built on TrueNAS, while native LXC turns your storage node into a compute node at the same time. Here is exactly what changes, what breaks, and whether your storage node should jump to the beta today or wait for stable.

Key Takeaways

• Pool versions: OpenZFS 2.4 bumps the ZFS pool format version, so an older Proxmox kernel module may not import a pool created on TrueNAS SCALE 26.
• Network first: Reach the pool over iSCSI or NFS from Proxmox instead of importing it, and the version gap stops mattering.
• WebShare: WebShare shrinks the clicks to stand up an NFS or SMB share, but the Proxmox mount options still decide what your VMs see.
• Native LXC: Native LXC lets TrueNAS run containers directly, which trades ARC headroom for compute on your storage node.
• Wait for stable: The beta is ideal for a second test node, but hold off on the pool that holds your only copy of important data.

How Does Your Proxmox Node Reach TrueNAS Storage?

Most PVE-plus-TrueNAS homelabs pick one of three paths, and the path you choose determines whether OpenZFS 2.4 even touches your workload.

With iSCSI, Proxmox presents a LUN from TrueNAS as a local disk. Your VMs write blocks to it, and the ZFS pool lives entirely inside TrueNAS. This is the setup in iSCSI Block Storage on Proxmox from TrueNAS SCALE, and it is the most common because it keeps the expensive part of ZFS off the compute node.

With NFS, Proxmox mounts a directory from TrueNAS as network storage. You add it with pvesm add, and Proxmox talks NFS over TCP. This is the path I reach for when I want a pool shared between several VMs without per-VM LUNs.

pvesm add nfs truenas_nfs \
  --server 192.168.1.50 \
  --export /mnt/pool/vms \
  --content images \
  --mountopts "vers=4.2"

With SMB, you share files to Windows or macOS clients, and Proxmox reads them through the guest. It is great for media and documents and almost never used for VM disks.

The key point for this release: in all three cases Proxmox never imports the ZFS pool. The pool lives in TrueNAS, and TrueNAS speaks OpenZFS 2.4 to the disks. Proxmox only sees a block or a network directory. That isolation is exactly why the pool-version question usually does not bite you.

Why Can't Proxmox Always Import a TrueNAS Pool?

The pool-version trap only appears when Proxmox actually imports the pool. This happens when you repurpose a disk that held a TrueNAS pool, or when you move storage between nodes in a small cluster.

ZFS pools are forward-incompatible. An older kernel module cannot import a pool that was written at a newer pool version, even though newer software always reads older pools. TrueNAS SCALE 26 ships OpenZFS 2.4, which brings a round of performance work on top of the new pool version, including Direct Raw Access (DRA) reads and ARC tuning. It writes pools at the newest pool version, and Proxmox VE 9 bundles its own zfs-dkms kernel module that often lags the upstream OpenZFS release by months.

Check what each side is running before you move a disk.

zpool status

The bottom of the output prints pool version: N. Compare that number to the kernel module on the Proxmox node.

zfs version

This prints the ZFS shell version and, more importantly, the kernel module version. If the TrueNAS pool version is higher than what this module supports, the import fails.

zpool import -d /dev/disk/by-id/ata-WDC_WD0000_xyz123 mypool

You will typically see the pool refuse to import, or import with a note that a feature is unsupported. The data are not gone; the pool just speaks a language this kernel module does not understand yet.

I hit this exact wall moving a twelve-disk RAIDZ2 pool between nodes. The pool imported on the new box only after I rebuilt the ZFS kernel module to match the newer OpenZFS, which on Proxmox means waiting for the backported package or compiling against a newer kernel. For a pool that large, with a full scrub that runs roughly five hours, I simply kept accessing it over iSCSI instead of importing it.

The practical fixes, in order of preference: access the pool over the network, update the Proxmox ZFS kernel module, or upgrade the running ZFS so zpool upgrade can catch up. Never force an import on a pool you do not fully understand the version of.

How WebShare Changes What You Share

WebShare in TrueNAS 26 lets you stand up an NFS or SMB share for a ZFS dataset from the web UI, instead of editing share configuration by hand. For a Proxmox homelab, that mostly shrinks the time to get a share live and reduces the chance of a typo in an export path.

But here is the honest tradeoff: WebShare makes the TrueNAS side faster, while the Proxmox side still governs what your guests actually receive. A share can be "created," yet Proxmox still applies its own mount options, and a mis-set mount option will make the storage invisible or slow regardless of how the share looks in TrueNAS.

That is why I still pin the NFS version explicitly, as in the pvesm add example above. Forcing vers=4.2 avoids a client that falls back to an older, slower NFS protocol and then looks broken at 3 AM.

WebShare also nudges the balance of control. When you can spin up shares from a browser, it is tempting to let every VM "own" its share. On a shared homelab pool, I keep share creation centralized and review the export list before it goes live, so one accidental world-writable dataset does not become everyone's problem.

Does Native LXC in TrueNAS Change Your Proxmox Math?

Native LXC in TrueNAS 26 means your storage node can run containers directly, not just serve ZFS. That is a genuine capability gain, but it changes the resource math on a box whose whole job is usually to keep the ARC large.

TrueNAS scales the ARC up and down against available RAM, and it reserves memory for the operating system and for any apps or containers you run. When you lean into native LXC and run workloads on TrueNAS, you are trading ARC headroom for compute. A smaller ARC means more disk reads under load, which is the opposite of what you want from a storage node feeding several VMs.

For a PVE-compute, TrueNAS-storage split, my recommendation is to keep the roles sharp. Let Proxmox run the containers and VMs, and let TrueNAS keep its ARC and its pools. If you do run containers on TrueNAS, watch the Arcsize cap and the overall RAM usage in the dashboard, and expect the pool to behave slightly differently under memory pressure.

This also reframes a common question: if TrueNAS can run containers natively, do you still need Proxmox? Yes, for most homelabs. Proxmox's KVM and LXC scheduling, clustering, and configuring VLANs on Proxmox with Linux Bridges give you a compute layer that TrueNAS is not built to be. Keep TrueNAS as the storage tier and Proxmox as the compute tier, and each does what it is best at.

Upgrade Now or Wait for Stable?

The answer depends on which copy of your data the TrueNAS pool holds. Here is the tradeoff laid out plainly.

Aspect	Beta	Stable
Stability	Known bug surface, occasional regressions	Polished and battle-tested
OpenZFS 2.4 features	Available immediately	Weeks to months behind
Pool version risk to Proxmox	Highest, newest pool version	Lower, mature pool version
Rollback path	Harder, pools may have moved forward	Easier
Best for	A second test node	Your only copy of important data

If the pool holds a single copy of your important data, wait for stable. The beta is the kind of release where a pool-version bump or an unpolished feature can leave you reading error messages instead of serving VMs.

If you have a second node or a test cluster, jump on the beta and validate OpenZFS 2.4 behavior there. Before you point real data at it, take a snapshot and confirm your backup job still runs.

zfs snapshot -r mypool@pre-upgrade-2026
zfs list -t snapshot

A snapshot is cheap insurance during a beta cycle, and pairing it with an Automated Backups with Proxmox Backup Server job means a bad upgrade rolls back to a known-good state. Then add a lightweight health check so you notice a degraded pool before a user does.

zpool status -x

Combine that with the kind of Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs you already run, and the beta becomes a validated experiment instead of a gamble.

Conclusion

TrueNAS SCALE 26's beta touches a Proxmox homelab in two concrete ways: OpenZFS 2.4 bumps the pool version, which can block an import on an older Proxmox kernel module, while native LXC turns your storage node into a compute node that competes with the ARC. The pool-version risk stays mostly theoretical when you access the pool over iSCSI or NFS, and WebShare only speeds up share creation without changing what Proxmox mounts. Take a ZFS snapshot and confirm your Proxmox Backup Server job before you upgrade, then decide based on whether that pool holds your only copy of important data.