Proxmox Needs a Coherent Storage Story More Than a TrueNAS Killer

The idea that sounds obvious until you touch it

Every popular platform eventually reaches the same awkward moment: users stop asking what it can do and start asking why the rest of their stack has to exist at all. Proxmox already runs the hosts. It already understands VMs, containers, ZFS pools, clustering, backups, permissions, and enough storage integration to make a home lab feel like a small private cloud. So the pitch almost writes itself: why not build a dedicated Proxmox storage product too? Call it ProxStorage, and make it simple, Debian-based and ZFS-only, with the app-store clutter, the plugin sprawl and the identity crisis stripped away. It would export NFS and iSCSI, let Proxmox manage snapshots cleanly, and give users one ecosystem instead of another appliance with another dashboard and another set of assumptions.

That idea hit a nerve because it speaks to something real. Plenty of people like TrueNAS for what it does best, but they're tired of watching storage platforms drift toward "everything box" territory. Apps, plugins, UI churn, product segmentation, commercial anxiety and shiny side projects all make some users want a boring storage appliance again. They don't want a Kubernetes playground, a media server launcher or a lifestyle brand for disks. They want a serious ZFS-backed storage target for virtualization, something that says: here are your pools, datasets, snapshots, NFS exports, iSCSI targets, replication jobs, and permissions. Please enjoy your sleep.

The appeal is obvious. A storage appliance built by the same people who build Proxmox VE could feel native in a way that TrueNAS, OpenMediaVault, XigmaNAS, or a hand-rolled Debian box never quite does. Imagine storage snapshots exposed in the Proxmox UI like backups, and VM-aware snapshot coordination without duct tape. Imagine a clean interface designed around serving PVE clusters instead of serving every possible NAS hobby, with fewer translation layers between "I need reliable VM storage" and "here is the thing doing that job."

That's the dream, and storage dreams have a nasty habit of turning into support nightmares.

TrueNAS is more than a file share with a nice UI

A lot of the early confusion came from people treating the proposal like it was about simple file sharing. One person asked why anyone would need TrueNAS if they could just run a tiny NAS VM inside Proxmox. Another pointed out that Proxmox already has ZFS pools and even a UI section for them. That's true, but it misses the meat of the idea. The proposal was closer to "give Proxmox a dedicated storage backend that competes with the SAN role TrueNAS often fills" than to "let me share a folder."

That distinction matters. TrueNAS came from a world where bare-metal storage was the point, and performance, replication, scalable pools, block storage, and clean management were the product itself. One commenter described running a bare-metal TrueNAS box with around 300TB of storage, some of it dedicated to iSCSI block storage that used to feed VMware and now feeds Proxmox. A micro-NAS VM serving a family photo share is a different animal. That box is infrastructure, a storage subsystem.

So the fair version of the ProxStorage idea is that Proxmox could round out its ecosystem with a converged storage product alongside hyperconverged Ceph, which is much more interesting than cloning TrueNAS because someone dislikes plugins. Ceph is already part of the Proxmox story, but Ceph is not a casual single-box storage appliance. It wants multiple nodes and planning. It wants network, disks, monitors, OSDs, failure domains, and a certain amount of emotional maturity. A NAS or SAN product can be useful precisely because it does not require three or more physical machines to be meaningful.

That point came up directly: a NAS should not require 3+ devices to function. Someone else pushed back that secure, scalable NAS absolutely has a place in a small company, even if a tiny home lab can get away with less. Both sides are right. A single storage appliance and a distributed storage cluster solve different problems, and pretending otherwise is how people end up angry at Ceph for not being a Synology, or angry at a NAS for not being a scale-out storage fabric.

The strongest support for the proposal came from people who understood this middle ground. A dedicated, Proxmox-managed ZFS and perhaps Ceph-aware storage target, built specifically for PVE, could be useful. TrueNAS isn't bad and the existing tools do work; the case rests on the gap in the Proxmox ecosystem between "local ZFS on each host" and "full Ceph cluster." That gap is where a lot of real small-business and lab storage lives.

The "just use what exists" crowd has a point

The other side of the argument is brutally practical: why should Proxmox build a whole storage product when the pieces already exist? You can build ZFS directly on a PVE node. You can export datasets through an LXC container running Samba, wrap XigmaNAS or another NAS OS in a VM, or hand-roll NFS and iSCSI on Debian. You can run TrueNAS bare metal, use OpenMediaVault, or buy a commercial SAN. The ecosystem is messy, but it is not empty.

One commenter suggested XigmaNAS, describing it as a long-running FreeNAS fork that offers much of what people ask for. Another suggested using LXC "Zamba" and exporting a ZFS dataset. Someone else noted that you can create a ZFS dataset on Proxmox and pass storage into a VM in a way that keeps the pool on PVE. None of these are fantasy suggestions. They are exactly how a lot of people solve this problem today: keep ZFS where Proxmox can see it, then use a lightweight service or VM to expose it.

The trouble is that "you can already do this" doesn't give you a coherent product around it. A hand-built ZFS export stack may work beautifully for the person who built it and be a confusing pile of assumptions for the next admin. TrueNAS exists because storage management involves far more than commands: lifecycle, permissions, alerts, replication, snapshots, sharing, monitoring, upgrades, and recovery. A Proxmox-native storage appliance would have to do all of that without becoming the bloated thing it was supposedly replacing.

That's the hard part. Everyone wants "simple," and nobody agrees where simple ends. Add only NFS and iSCSI, and someone immediately asks about SMB. Add SMB, and someone asks about object storage. Add object storage, and now you're drifting toward the same feature sprawl people were trying to avoid. Add apps, and the pitch dies completely; leave them out, and a chunk of the NAS market shrugs and stays where it is. Product focus sounds easy until every missing feature is someone's dealbreaker.

There was also a reasonable procedural complaint: feature requests belong in Bugzilla, not just in casual discussion. That's not a romantic answer, but it's the grown-up one. If the goal is to attract developers, a real feature request needs scope, use cases, non-goals, integration points, and a reason it would help the business behind Proxmox. "Please build a storage OS" asks for a whole product line.

The TrueNAS anxiety is really about trust

The criticism of TrueNAS had an emotional edge. It went beyond "I prefer a different interface" to "this thing feels bloated, the UI keeps changing, and what if it becomes more commercial?" That fear is common in open-source-adjacent communities. People build their homes, labs, and businesses on a tool, then watch the company behind it evolve. Suddenly there are new products, new branding, new priorities, and users start wondering whether they're still the audience.

Some of that anxiety may be unfair. TrueNAS still fills an important role and has a long track record. There's nothing wrong with a storage product having a polished UI, commercial offerings, or broader ambitions. Businesses need money, developers need salaries, and hardware vendors need customers. A project staying alive usually means someone is paying for the oxygen.

But the discomfort is still real. Users who want a storage appliance for Proxmox don't necessarily want an all-purpose NAS platform with a personality. They want something quieter, with fewer opinions outside its lane, something that doesn't feel like it might become another ecosystem they have to decode. In that sense, the ProxStorage idea is less about hating TrueNAS and more about wanting storage that feels like part of the same operational brain as Proxmox.

That's why the snapshot idea matters. "VM can see snapshots native to ProxStorage" may sound vague, but the desire underneath it is sharp: users want storage-aware virtualization without clumsy boundaries, where the hypervisor, storage target, and backup system understand one another. Proxmox Backup Server already shows how valuable that ecosystem thinking can be, because it fits the way PVE thinks about backups instead of just storing files. A Proxmox storage appliance could, in theory, do the same for shared storage.

Still, trust cuts both ways. Users may trust Proxmox, but Proxmox would have to earn trust in a new category. Storage appliances are judged harshly because data loss is unforgivable. A rough edge in a VM UI is annoying; a rough edge in storage replication or iSCSI behavior can become a business-ending event. A "no worry storage" product sounds beautiful, and it also sounds like a hostage note from the future support queue.

The missing product is real, and so is the trap

The most compelling version of ProxStorage would be narrow: Debian-based and ZFS-first, with no app store and no Docker theater. It would have strong NFS and iSCSI, and clear SMB support only if the product is willing to own it properly. Add Proxmox-native authentication, snapshot and replication workflows that line up with PVE, good monitoring, great alerts, first-class documentation, and a clean upgrade path. Maybe it offers optional Ceph integration for larger designs, without forcing a Ceph-first story. In short, a storage appliance for people who want a SAN/NAS companion to Proxmox rather than a lifestyle NAS.

That could be powerful. It would give small shops and labs a cleaner alternative to "install TrueNAS bare metal and wire it up" or "do a bunch of custom Debian storage work and hope everyone documents it." MSPs and internal IT teams would get a more consistent support story, and users who want shared storage without the complexity of Ceph or the sprawl of a general NAS appliance would have somewhere to go. It would extend the ecosystem in a way that feels natural.

But it would also compete for developer attention against everything Proxmox already has to maintain: PVE, PBS, Mail Gateway, SDN, clustering, HA, Ceph integration, ZFS integration, backup improvements, UI work, kernel issues, hardware support, documentation, and enterprise support. Debian and ZFS already existing doesn't make a storage product "not much work." The packages are the cheap part; the integration, testing, guardrails, and support are where the expense sits.

And the community would immediately split. Some would say, "Finally, a clean Proxmox SAN." Others would say, "Why duplicate TrueNAS?" Some would want Ceph baked in, some would demand SMB, and some would want object storage. Some would want a single-node appliance and others HA storage. Some would insist a NAS should be simple, while others would insist simple is irresponsible. The product would be born into a thousand expectations.

None of that rules it out, but the proposal needs discipline. "Replace TrueNAS" is too broad, too emotional, and probably unnecessary. The better idea is "build a Proxmox storage appliance focused on being the best shared storage backend for PVE," which is a cleaner target. It doesn't need to win the whole NAS world. It needs to solve the Proxmox storage gap better than the current patchwork.

The best ideas usually start as complaints

What makes this discussion interesting is that the original pitch was messy while the instinct behind it was strong. People do want storage that feels native to their virtualization platform, with less bloat and an option between local ZFS and full Ceph. They do want snapshots, replication, NFS, iSCSI, and PVE integration without juggling a separate universe. And yes, some people are tired of watching storage platforms become app platforms with disks attached.

The critics had a point too. Proxmox already has ZFS, and plenty of NAS tools already exist. TrueNAS is more than bloat, and XigmaNAS, OMV, hand-built Debian, and simple container exports can already cover many use cases. A new product would bring support burden, scope creep, and a thousand ways to disappoint people. "No worry storage" is the kind of phrase that sounds great until the first user loses a pool because they clicked through a warning they didn't understand.

There are really three camps here. The first wants a Proxmox-native storage appliance because the ecosystem feels incomplete without one. The second says the existing tools are enough, and Proxmox should not burn energy reinventing storage management. The third sees the bigger shape: there may be room for a converged storage product, but only if it stays focused on serving Proxmox clusters rather than chasing every NAS feature under the sun.

That third camp is probably closest to the truth. Proxmox doesn't need to kill TrueNAS, clone it, or become another bloated NAS with an app catalog and an identity crisis. But a clean, focused storage companion built around ZFS, shared block/file exports, snapshots, and PVE-aware workflows is far from a silly idea. It's the kind of missing piece users start asking for when a platform becomes important enough to organize their whole lab or business around.

What remains open is whether Proxmox wants that responsibility. Building storage is easy in the same way building a bridge is easy: the shape is obvious, the materials exist, and everyone agrees where the other side is. The hard part is making people trust it when they drive across.