TrueNAS SMB Security: AES-128/256, SMB3 Signing, and What Admins in SMB Shops Should Change Now

SMB has been the workhorse for file sharing in Windows networks for years — which is exactly why it is worth taking an honest look at how secure it actually is in your environment. In many setups we take over, we still find SMB1 enabled, no signing, no encryption, and an audit log that nobody has ever looked into. This article shows how we set up TrueNAS SMB security when we take over or build a new file server for a small or midsize company — with a focus on SMB3 signing, AES-128/256-GCM, clean client compatibility with Windows 11 and Server 2025, and an audit trail that actually tells you something when it matters.

Why TrueNAS SMB security is no longer optional in 2026

File shares are usually the most valuable target in a company network. Anyone who can decrypt, read, or quietly modify data there has access to contracts, accounting, engineering drawings, and client files. At the same time, ransomware reports, recent attacks via protocol downgrades, and the discussion around NIS2 and CER make it very clear: protocol hygiene belongs to the baseline, just like backups and patch management.

In practice that means:

• SMB1 has to go. Not “at some point”, but before the next audit discussion.
• SMB3 signing is enforced, not just recommended.
• SMB3 encryption with AES-128-GCM or AES-256-GCM is the default for sensitive shares.
• Audit logging runs continuously and ships to a central log target for at least 90 days.

The good news: TrueNAS 25.10 Goldeye ships with these building blocks out of the box. We just need to turn them on consistently and align them with the clients.

Disable SMB1 — yes, still

Even in 2026 we still find SMB1 enabled in an alarming number of environments. Usually it is a scanner MFP, an old document capture system, a machine controller, or a backup script from the Windows XP era. SMB1 is broken, known-broken, and has been disabled in Microsoft defaults for years. Still, someone re-enables the service “because otherwise the scanner stops working.”

Our approach on TrueNAS:

Shares > SMB > Advanced
  Server Minimum Protocol: SMB3_02
  Server Maximum Protocol: SMB3_11
  Enable SMB1 Support: off

What does that mean in practice? Anything that cannot speak at least SMB2 loses access. That is why we always start with a quick inventory:

• Which devices talk to which share today? A look at the SMB session log on TrueNAS shows us the clients with their protocol version.
• Which MFPs and scanners are active? They either get a firmware update, an SMB2-capable file share workflow, a separate scan-to-mail process, or they end up in a tightly segmented, non-routed VLAN with its own scan share — isolated from the production file server.
• Are there legacy applications that strictly need SMB1? In 95 percent of cases, the answer is “no, the vendor released an SMB2 version two years ago, it just was never applied.”

Important: we never disable SMB1 silently. We coordinate with the business units beforehand. A dead scanner on Monday morning is exactly the kind of event that turns a clean security project into a flood of tickets.

Enforce SMB3 signing

Signing makes sure SMB packets have not been modified in transit. Without signing, classic NTLM relay patterns are significantly easier because an attacker can redirect the authenticated session and trigger file operations under someone else’s name. With enforced signing, modified packets become invalid.

On TrueNAS, in SMB advanced settings:

Server Signing: required
Client Signing: required (if TrueNAS also acts as an SMB client)

In addition, we check the domain policy on the Windows server:

• “Microsoft network server: Digitally sign communications (always)” = Enabled
• “Microsoft network client: Digitally sign communications (always)” = Enabled

Signing costs CPU cycles, but on current CPUs with SHA hardware acceleration the overhead is no longer noticeable in mixed office workloads. Where we stay cautious: high-frequency, many-small-files workloads on older clients with weak CPUs. Here we test first.

Enable AES-128-GCM and AES-256-GCM

Signing protects integrity, encryption protects confidentiality. SMB3 can use AES-128-CCM, AES-128-GCM, AES-256-CCM, and AES-256-GCM. GCM is significantly faster than CCM and is preferred by Windows 11, Windows Server 2022, and Server 2025.

Our recommendation for production:

• AES-128-GCM as the minimum. That is the default on TrueNAS 25.10 and sufficient for the majority of SMB-shop workloads.
• AES-256-GCM enforced on shares with client data, payroll data, engineering data, and on all shares in regulated environments (CER-covered sectors, tax advisors, law firms).

Per share on TrueNAS:

Shares > SMB > <Share> > Edit > Advanced
  SMB Encryption: required

Plus at the server level:

Shares > SMB > Advanced
  Encrypt all SMB traffic: optional or required

“Optional” leaves the choice to the client — if the client offers encryption, it will be used. “Required” enforces it globally. For pure Windows 11 and Server 2025 environments we set “required”. For mixed environments with older Linux clients, certain thin clients, or print server workflows we only set “required” per share.

Important: encryption does not replace signing. Both together is the goal.

Compatibility with Windows 11 and Server 2025

Microsoft tightened defaults significantly with Windows 11 24H2 and Server 2025. SMB1 is not only disabled there, it cannot even be reinstalled on fresh installs. SMB signing is enforced by default on both. Guest logins to SMB shares are blocked. From a security point of view that is excellent — but in mixed environments it regularly causes problems when:

• an old NAS share still uses guest access,
• a scanner MFP writes scans into a share using a passwordless service user,
• a Linux client with an old cifs-utils version does not speak current SMB3 dialects.

Our approach: before rollout, we check clients with Get-SmbConnection (Windows) and look at the negotiated dialect version and the signing/encryption flags. Anything below 3.1.1 is documented and either upgraded or moved into a separate VLAN with its own legacy share. More background in our article on TrueNAS SMB Active Directory setup.

Legacy devices and scanners — the honest take

We deliberately do not sell “just flip the switch.” Realistically there are three paths:

1. Firmware update: many MFPs — Konica Minolta, Kyocera, Xerox, Canon imageRUNNER — have received firmware with SMB2/SMB3 support since 2023. Updates are often free but are not applied automatically.
2. Scan-to-mail or scan-to-cloud: often the clean alternative for small office environments when the scanner can no longer talk to a classic file share.
3. Separate legacy scan share in an isolated VLAN: only when paths 1 and 2 do not work. In that case: a dedicated user with a password, no access to other shares, continuous audit logging, no routing toward production.

Important: legacy devices are not a reason to re-enable SMB1 globally. They are a reason for a clearly scoped legacy segment with an expiration date.

Audit logging — without it, nobody sees the attack

The best SMB configuration helps little if, when it matters, you cannot tell which user touched which file when. TrueNAS can log SMB activity per share or globally through its SMB audit configuration. We enable:

• logon/logoff events,
• successful and failed access to sensitive shares,
• deletions,
• renames (especially interesting during ransomware — the typical signature is “many renames in a short time with a new extension”).

Logs ship via syslog to our central SIEM — for smaller customers to a lightweight open-source solution like Graylog or Wazuh, for larger ones to an existing system. At least 90 days retention, ideally 180. If you are moving toward CER, you need a complete audit chain anyway.

Concrete rollout order for a production system

Because order matters here, this is our usual rollout for customers:

1. Inventory: capture SMB dialects and clients, identify legacy devices.
2. Communicate with the business units, define a change window.
3. Enable audit logging first — deliberately so, so we can compare before and after cleanly.
4. Set SMB signing to “required”, test with clients.
5. Enable SMB encryption per share, starting with sensitive shares.
6. Disable SMB1 on the server.
7. Move legacy devices into a separate VLAN with a legacy share, note an expiration date.
8. Two weeks later: review audit logs, work through client issues.

For the hardware side of the file server, our TrueNAS Configurator is a good starting point — for consulting and implementation by our team, there is TrueNAS Support. If you also want SMB to perform, the article on SMB Multichannel over 10 GbE covers the matching network configuration.

FAQ

Is SMB signing enough without encryption?

Signing protects packet integrity but not confidentiality. Without encryption, an attacker with network access can still read the content. In regulated environments and with client data, we therefore use both.

What does AES-256-GCM actually add over AES-128-GCM in practice?

Both are considered secure. AES-256-GCM has a larger security margin against future attacks and is often explicitly required in regulated sectors. For pure office workloads on current CPUs, the performance difference is not noticeable in daily use.

Do I really have to disable SMB1 globally even if just one scanner needs it?

Yes. An active SMB1 service is available to every attacker on the network, not only to the scanner. For the individual case there are firmware updates, scan-to-mail, or an isolated legacy share. Leaving SMB1 globally enabled just because one device is old is not defensible from a risk perspective.

Which audit data should we keep at a minimum?

We recommend logon/logoff, file access to sensitive shares, deletions, and renames — at least 90 days, in regulated sectors 180 days or more. Stored centrally, not only on the NAS, so an attacker cannot encrypt the trail along with everything else.

What does a typical SMB-shop rollout cost?

That depends heavily on the number of clients, the state of legacy devices, and the existing monitoring. As a frame: for a smaller project with 20 to 50 clients, a TrueNAS, and an existing AD, we usually plan one to two implementation days plus prep and follow-up. Concrete numbers on request through our contact page.

How does this fit a later upgrade to TrueNAS 27?

The SMB settings described here remain compatible with the upgrade to TrueNAS 27, which is expected GA in early December 2026. All protocol hygiene steps you implement today on 25.10 Goldeye carry forward. More on this in our article on the TrueNAS 27 rename.