Proxmox Doesn’t Need a TrueNAS Killer. It Needs a Storage Story That Makes Sense.

# Proxmox Doesn’t Need a TrueNAS Killer. It Needs a Storage Story That Makes Sense. ## 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. Make it simple. Make it Debian-based. Make it ZFS-only. Strip away the app-store clutter, the plugin sprawl, the identity crisis. Export NFS and iSCSI. Let Proxmox manage snapshots cleanly. 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, shiny side projects — it all makes some users want a boring storage appliance again. Not a Kubernetes playground. Not a media server launcher. Not a lifestyle brand for disks. Just 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. Imagine VM-aware snapshot coordination without duct tape. Imagine a clean interface designed around serving PVE clusters instead of serving every possible NAS hobby. Imagine fewer translation layers between “I need reliable VM storage” and “here is the thing doing that job.” That’s the dream. The problem is that storage dreams have a nasty habit of turning into support nightmares. ## TrueNAS Isn’t Just 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 wasn’t really “let me share a folder.” It was “give Proxmox a dedicated storage backend that competes with the SAN role TrueNAS often fills.” That distinction matters. TrueNAS came from a world where bare-metal storage was the point. Performance, replication, scalable pools, block storage, and clean management were the product, not a side quest. 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. That’s not the same as a micro-NAS VM serving a family photo share. That’s infrastructure. It’s a storage subsystem. So the fair version of the ProxStorage idea is not “Proxmox should clone TrueNAS because I don’t like plugins.” It’s “Proxmox could round out its ecosystem with a converged storage product, not just hyperconverged Ceph.” That’s much more interesting. Ceph is already part of the Proxmox story, but Ceph is not a casual single-box storage appliance. It wants multiple nodes. It wants 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 is not the same thing as a distributed storage cluster, and pretending they solve the same problem 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. Not because TrueNAS is bad. Not because existing tools don’t work. Because the Proxmox ecosystem has a gap 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 Isn’t Wrong 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. You can wrap XigmaNAS or another NAS OS in a VM. You can hand-roll NFS and iSCSI on Debian. You can run TrueNAS bare metal. You can use OpenMediaVault. You can use a commercial SAN. The ecosystem is not empty. It’s 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. These are not 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” is not the same as “there is a coherent product around this.” A hand-built ZFS export stack may work beautifully for the person who built it. It may also be a confusing pile of assumptions for the next admin. TrueNAS exists because storage management is not just commands. It’s 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.” 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. Don’t add apps, 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” is not a small ask. It’s a product line. ## The TrueNAS Anxiety Is Really About Trust The criticism of TrueNAS had an emotional edge. It wasn’t just “I prefer a different interface.” It was “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. It’s not wrong for a storage product to have a polished UI, commercial offerings, or broader ambitions. Businesses need money. Developers need salaries. 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. A storage target 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. They want the hypervisor, storage target, and backup system to understand one another. Proxmox Backup Server already shows how valuable that ecosystem thinking can be. It doesn’t just store files. It fits the way PVE thinks about backups. 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. It also sounds like a hostage note from the future support queue. ## The Missing Product Is Real, But So Is the Trap The most compelling version of ProxStorage would be narrow. Debian-based. ZFS-first. No app store. No Docker theater. Strong NFS and iSCSI. Clear SMB support only if the product is willing to own it properly. Proxmox-native authentication. Snapshot and replication workflows that line up with PVE. Good monitoring. Great alerts. First-class documentation. A clean upgrade path. Maybe optional Ceph integration for larger designs, but not a forced Ceph-first story. Basically: a storage appliance for people who want a SAN/NAS companion to Proxmox, not 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.” It would give MSPs and internal IT teams a more consistent support story. It would help users who want shared storage but don’t want the complexity of Ceph or the sprawl of a general NAS appliance. 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. A storage product is not “not much work” just because Debian and ZFS already exist. The value is not the packages. The value is the integration, testing, guardrails, and support. That’s the expensive part. 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. Some would want object storage. Some would want a single-node appliance. Some would want HA storage. Some would insist a NAS should be simple. Some would insist simple is irresponsible. The product would be born into a thousand expectations. That doesn’t mean it shouldn’t exist. It means the proposal needs discipline. The winning idea is not “replace TrueNAS.” That’s 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.” That 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, but the instinct behind it was strong. People do want storage that feels native to their virtualization platform. They do want less bloat. They do want an alternative 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. Existing NAS tools already exist. TrueNAS is not just bloat. 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. It doesn’t need to clone it. It doesn’t need to become another bloated NAS with an app catalog and identity crisis. But a clean, focused storage companion built around ZFS, shared block/file exports, snapshots, and PVE-aware workflows? That’s not a silly idea. That’s the kind of missing piece users start asking for when a platform becomes important enough to organize their whole lab or business around. The real question is whether Proxmox wants that responsibility. Because 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.