TrueNAS makes file servers, also known as Network Attached Storage (NAS). I bought one of their smaller boxes to house backups, and it’s a great little NAS. For many years TrueNAS sold boxes with a BSD-based operating system, but in the last few years they’ve released a new, Linux-backed operating system called TrueNAS SCALE, also called “Community Edition”. I was considering migrating to TrueNAS SCALE, but the docs started off with this warning:

TrueNAS Enterprise customers should consult with TrueNAS Enterprise Support before attempting migrate.

The process requires an extended maintenance window, requires executing steps in the correct order to prevent issues with system configuration and operation, and additional system review post-migration to catch and correct any configuration issues.

Since I’d actually purchased their hardware, I wrote to their support email. I asked whether the BSD-based OS was reaching end-of-life, and if there was anything special I should know about the upgrade process for my particular machine. The response came from a customer success coordinator, whose name I’ll omit for privacy. It began:

Hi Kyle,

It sounds like you’re at an important crossroads with your TrueNAS Mini 3.0-X+ system as it transitions from the traditional BSD-based OS to the Linux-based SCALE platform, now known as TrueNAS Community Edition.

Understanding the Transition
End-of-Life for Certain Versions: The BSD-based version of TrueNAS you’re currently using (TrueNAS-13.0-U6.7) may be reaching its end-of-life phase, prompting a move to newer systems like TrueNAS SCALE, which is based on Linux and offers more modern features.

Community Edition: The Community edition represents the transition towards a more flexible, open-source platform that leverages FreeBSD jails (similar in concept to containers) for virtualization, providing scalability and extensibility.

The phrase “may be reaching its end-of-life phase” was immediately worrying: how does a TrueNAS support agent not know whether their own products are EOL? But what really shocked me was the blatant lie in the third paragraph: they told me that the new OS was based on Linux, then immediately turned around and said that the new system was based on FreeBSD. FreeBSD jails were TrueNAS’s old approach to virtualization; the new Community Edition uses Docker containers. I could not believe that a human being had actually skimmed this response, let alone written it. I was, I think, talking to a Large Language Model (LLM) wearing the face of a person.

The response went on, coining odd phrases and warning of unspecified risks. “Non-HA (Non-Redundant Array of Independent Disks) TrueNAS hardware can sometimes have specific requirements or limitations when migrating to TrueNAS Community Edition,” they said. RAID and HA are different things in TrueNAS. Moreover, the reason I wrote to support in the first place was to ask what those “specific requirements” were. I was hoping for a support article I’d somehow missed, or a canned response. Instead I got my own question, regurgitated as a warning.

I wrote with followup questions, and got more nonsense in response. When I asked how TrueNAS Community Edition used FreeBSD jails, a different customer success coordinator replied:

FreeBSD jails are similar to containers (like Docker) but built into the FreeBSD system. TrueNAS uses them to run isolated apps and services. For example, you can run Plex, Nextcloud, or other apps safely and separately using jails — all within your TrueNAS system.

They’re lightweight, secure, and don’t need a full virtual machine to run each service. It’s a great way to expand what your system can do without using much extra power or memory.

This is all lies. TrueNAS CORE, the old FreeBSD OS, ran jails. TrueNAS SCALE / Community Edition runs Docker containers.

Quoting their HA/RAID confusion, I asked whether for TrueNAS hardware, the two were actually the same.

Good question — they’re different:

• RAID protects your data by spreading it across multiple disks, so if one disk fails, your data is still safe.

• HA (High Availability) means the system has two controllers. If one fails, the other takes over so the system keeps running. This is used in high-end enterprise systems (like our TrueNAS M-series), not in the MINI line.

This is, I believe, accurate, but betrays no sign that the original response conflated the two.

I asked what specific limitations my NAS model had that would cause issues migrating to Community Edition. They replied:

The MINI-3.0-X+ is compatible with Community Edition (TrueNAS CORE), but there are a few things to know:

• No Enterprise-only features: Some features like enclosure management and support alerts are only available in the Enterprise version.

• No HA support: Not an issue for the MINI, since it’s a single-controller system anyway.

• Support level: CORE is community-supported, so it doesn’t come with iXsystems support like the Enterprise version does.

But overall — the MINI runs CORE just fine for most use cases!

This sounds like a reasonable response, but it too is complete nonsense. TrueNAS CORE is a completely different operating system. I asked whether it would run Community Edition, also known as SCALE.

I worked support for many years, helping people with desktops, systems and networking, and occasionally for web services. I’m used to knowledge base articles and canned responses on both ends—and indeed, that’s exactly what I was hoping TrueNAS would provide. All I needed to know was why the documentation warned their customers to contact support before upgrading. Instead I got a pile of vague nonsense and lies.

I get it. Support is often viewed as a cost center, and agents are often working against a brutal, endlessly increasing backlog of tickets. There is pressure at every level to clear those tickets in as little time as possible. Large Language Models create plausible support responses with incredible speed, but their output must still be reviewed by humans. Reviewing large volumes of plausible, syntactically valid text for factual errors is exhausting, time-consuming work, and every few minutes a new ticket arrives.

Companies must do more with less; what was once a team of five support engineers becomes three. Pressure builds, and the time allocated to review the LLM’s output becomes shorter and shorter. Five minutes per ticket becomes three. The LLM gets it mostly right. Two minutes. Looks good. Sixty seconds. Click submit. There are one hundred eighty tickets still in queue, and behind every one is a disappointed customer, and behind that is the risk of losing one’s job. Thirty seconds. Submit. Submit. The metrics do not measure how many times the system has lied to customers.