SMB is the only remote file system protocol shared by Windows, MacOS, and Linux. Containers in general and Kubernetes specifically are the cutting edge of app development. Fusion is the ideal solution for the intersection of all these products into new workloads and scenarios, and this article details why.

Heya folks, it’s Ned Pyle again. Containers are one of the most compelling Tuxera Fusion SMB server scenarios. Fusion doesn’t just bring the best SMB performance and security story to Linux, it also consumes few resources and supports all features in user-mode, making it ideal for Docker and Kubernetes scenarios. Today we’ll talk about the benefits of running Fusion in a container, demonstrate its capabilities, and compare with Samba and Windows Server.

SMB server container benefits

Containers are lightweight vehicles, often running in large fleets scaled up and down on demand. App containers are usually “cattle, not pets”, quick to deploy with much shorter lifespans than physical servers and virtual machines. But what organizations really value in any system is the data, and these applications need a place to store and share it. Once you’re all-in on containers, you want a consistent management story for the entire workload, and that means data too. This is where Fusion SMB comes in.

Fusion SMB and containers

With Tuxera Fusion containers, there are no compromises. You still get multichannel, RDMA, compression, continuous availability, persistent handles, and an SMB 3.1.1 protocol from a licensed, patent-protected Microsoft partner. You still get Active Directory integration, Windows ACLs, Kerberos, OpenLDAP, encryption, and signing for all your security needs. Your performance continues to be the best of SMB on Linux.

Let’s see this in action. I’ve fired up a new Fusion container on Ubuntu from a private Docker repo, joined it to the contoso.com domain, configured Kerberos, and configured a share, all with a single command.

First, note the start time and finish times for creating the new file server:

I just deployed a domain-joined, Kerberos-enabled SMB file server in 2 seconds!
Now let’s look at performance. I’ve got a Windows 11 client, containers for Fusion and a Dockurr/Samba image, Fusion and Samba on the Ubuntu host, and a Windows Server 2025 machine. Each gets 8 vCPUs and 4GB of memory from their Hyper-V host. Then I run a single-threaded robocopy job of ~1,400 files; 21GB of travel photos averaging 15MB each – just a common user operation you’d expect every day:

Here are my results copying from Windows 11 to different SMB servers (higher MB per second throughput is better).

Interesting observations:
1. Throughput of Fusion SMB in a container and in the host is about the same; I don’t have to choose one for performance and if I’d multi-threaded my copy I’d be running at the limits of my storage and network here.
2. The Samba host performance is a little lower than Fusion, as I’d expect with such an easy copy job (it would be significantly lower with aggressive data scenarios like we’ve demonstrated around High Performance Computing, Media and Entertainment, Cloud, and Software-defined Storage).
3. The Samba container performance is by far the lowest. This might be affected by the image itself, but regardless, it’s not ideal that a popular, up-to-date Samba image runs so slowly in comparison.
4. Fusion SMB is faster in a user-mode container than my Windows Server is with kernel-mode SMB and 30 years of tuning! It’s likely that file system filters, drivers, and memory manager are the factors, not SMB itself (after all, the Windows client never changes here), but Fusion server has better throughput on identical hardware in my tests than Microsoft themselves, even while running on Microsoft’s own hypervisor!

Speaking of hardware, my Fusion SMB container’s utilization under that copy load is extremely low:

And here’s the proof that I’m using AES-256 Kerberos and Active Directory when connecting to my container; no need for NTLM or local users:

So: the performance is excellent, the security is excellent, and I’ve not had to compromise anything for my Fusion SMB server on a Linux container.

Where’s the Windows SMB container?

Notice that I didn’t have a container for my Windows server test. There are tens of millions of Windows Servers running SMB, so it makes sense it would be a good container to test, right? There’s a problem with that: Windows SMB server containers are impossible. Note this diagram from About Windows containers | Microsoft Learn.

The Windows implementation of SMB server lives almost entirely in the kernel as part of the SRVNET, SRV2, and SMBDIRECT.SYS drivers, with only the management and upper API layers living in user mode through LanmanServer. Windows containers are heavily isolated from the kernel’s interfaces and this architecture means Windows cannot containerize SMB servers. When I owned the protocol at Microsoft, I proposed a user-mode version of SMB for this very reason (it was never funded). Windows containers using SMB as a client also require a special – arguably, less secure – operation called global mapping to even connect to a server. Despite Windows Server having a large place in SMB globally, its presence in containers is exactly zero, perhaps forever.

Evaluate Tuxera Fusion SMB

All of this adds up to Tuxera bringing the best SMB server you can buy. It doesn’t just beat the other Linux competitors; it surpasses Windows too. Fusion is quite a system for your workload needs.

If you’d like to see all this for yourself and talk to an expert, visit our evaluations page.