Skip to main content
Auto-generated content — pending SME review

This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.

Objection Handling

Sourced from Fusion SMB Battlecard v1

The objection responses below are derived from the official Fusion SMB Battlecard. Sales/PMM — please refine based on field experience and add objections from real conversations.

How to Use This Guide

Each objection follows a structured format:

  • Objection — What the customer or prospect says
  • What They Really Mean — The underlying concern
  • Response Framework — How to address it
  • Proof Points — Evidence to back up your response

Objections are grouped into four categories. When in doubt, identify the underlying category and pick the closest framework as a starting point.


Performance & Technical Objections

"We're happy with our current file server performance"

What They Really Mean: They haven't measured, or their workloads haven't yet hit the ceiling.

Response Framework:

  1. Reframe: don't need it, or don't need it yet?
  2. Ask about their growth trajectory — more users, larger files, new workloads (AI/ML, video, simulation)?
  3. Share concrete benchmarks — Fusion SMB delivers ~11.4 GB/s on 100GbE RDMA and 20.4 GB/s on 200GbE per single client, vs Samba's ~2.4 GB/s ceiling
  4. Position Fusion SMB as future-proofing — capacity they'll need, not just what they need today

Proof Points:

  • Single client benchmarks: 11.4 GB/s (100GbE RDMA) / 20.4 GB/s (200GbE) vs Samba ~2.4 GB/s
  • SMB Direct (RDMA) capability for latency-sensitive workloads
  • Multi-threaded architecture scales with hardware
  • Fusion SMB ability to push data at near storage and network line rates

"Samba works fine for us — it's good enough"

What They Really Mean: They have small-business workloads being met today, or haven't hit performance/scale ceilings yet.

Response Framework:

  1. Agree — Samba is perfectly acceptable for small businesses with few users and light load
  2. Ask about modern requirements: high performance, large clusters, cluster rolling upgrades with zero downtime, RDMA, compression, enterprise scale
  3. Position Fusion SMB as the only option capable of meeting enterprise-scale needs
  4. The cost of being wrong: forklift migration to a new platform when you outgrow Samba

Proof Points:

  • Samba is process-based (1990s architecture); Fusion is multi-threaded for 21st-century workloads
  • Cluster ceiling: Samba 4–16 nodes vs Fusion 32 nodes
  • Cluster rolling upgrades with zero downtime — Samba does not support this
  • Real-world IBM Storage Scale customer: 11 Samba protocol nodes vs 4 Fusion SMB nodes for equivalent throughput
  • Reliability under load: in sustained random 4K write tests, Fusion holds 100% of clients while Samba drops 49% — when Samba runs out of cores for its per-connection processes, it doesn't slow down, it fails clients outright
  • Small-file workloads: up to 61× faster file creation (Fusion 2,307 files/sec vs Samba 40 files/sec on a 30,000-file vdbench test)

"We need SMB on Windows, not Linux"

What They Really Mean: They assume SMB = Windows, or their team lacks Linux expertise.

Response Framework:

  1. Acknowledge their Windows investment
  2. Explain that Fusion SMB provides native Windows client experience — AD auth, Kerberos, ACLs, Access-Based Enumeration, Windows Explorer works identically
  3. Highlight the Linux advantages: no CAL licensing, far lower OS overhead, runs alongside NFS, supports containers and ARM (Windows Server doesn't)
  4. There is no compromise — you simply get a better version of Microsoft's own product

Proof Points:

  • Full Active Directory, Kerberos, Windows ACL, ABE support
  • OS memory: Fusion 32MB minimum / 1GB recommended; Windows Server 512MB / 4GB
  • Microsoft SMB protocol patent licensee — full compliance
  • See also: "We're a Microsoft shop" below

"Does it work with our existing storage?"

What They Really Mean: They're worried about a forklift upgrade.

Response Framework:

  1. Fusion SMB works with any POSIX file system — ext4, XFS, ZFS, NTFS
  2. For clustering: supports GlusterFS, WekaFS, CephFS, Lustre, GPFS, GFS2, OCFS2
  3. Runs on standard Linux servers — no proprietary hardware required

Proof Points:

  • Documented support for all major file systems
  • Active-active and active-passive modes with customer-chosen storage
  • Real customer: deployed alongside IBM ESS 3500 / IBM Storage Scale (GPFS)

"We don't need scalability"

What They Really Mean: Their current scale is manageable, or they don't anticipate growth.

Response Framework:

  1. Reframe: don't need it, or don't need it yet?
  2. Fusion SMB scales from a single server to a 32-node active-active cluster — same protocol, same code, no migration
  3. The alternative is a full platform migration when you outgrow Samba's clustering ceiling
  4. With Fusion, you don't migrate — you add nodes

Proof Points:

  • Scale-out architecture: 1 → 32 nodes
  • Samba clustering: typically capped at 4–16 nodes, often unstable at scale
  • Distributed clustered file system support means you never need to re-platform

"We're not using RDMA"

What They Really Mean: Their network doesn't have RDMA NICs today, or they're unfamiliar with the technology.

Response Framework:

  1. Reframe: not using it, or not using it yet?
  2. 25Gb and 100Gb RDMA-capable NICs are now standard on most OEM servers
  3. RDMA isn't just about throughput — it's about CPU efficiency. Lower CPU on the file server frees cycles for actual workloads
  4. Fusion SMB supports both TCP and RDMA. Pick whichever fits today; you're not locked in

Proof Points:

  • Mainstream OEM servers ship with RDMA-capable NICs by default
  • Benchmarks: 11.4 GB/s on 100GbE RDMA, 20.4 GB/s on 200GbE
  • RDMA bypasses kernel TCP stack — significantly lower CPU load and latency

Cost & Commercial Objections

"Samba is free — why should we pay for Fusion SMB?"

What They Really Mean: They see file serving as a commodity and haven't quantified the cost of limitations.

Response Framework:

  1. You get what you pay for. With Samba: no SLAs, no guarantee of fixes or features, support from a community forum
  2. Quantify the gap: ~10× performance difference, no RDMA, no compression, limited clustering, no patent protection
  3. Calculate the hidden costs: engineering time maintaining Samba configs, troubleshooting performance, no SLA-backed escalation
  4. Frame it as: "Free software with expensive problems vs. commercial software with predictable costs and partnership"

Proof Points:

  • 11.4 / 20.4 GB/s vs ~2.4 GB/s throughput comparison
  • Commercial support with SLAs and dev escalation
  • Samba uses GPLv3 — legal risk for products distributed to customers
  • [TCO comparison data — Sales]

"We already have Windows Server licenses"

What They Really Mean: The switching cost seems high relative to the benefit.

Response Framework:

  1. Reframe: this isn't about replacing Windows Server everywhere — it's about using the right tool per workload
  2. High-throughput file serving on Linux can free Windows licenses for other roles
  3. Long-term: CAL costs compound with scale; Fusion SMB licensing is more predictable
  4. Plus: containers, ARM, modern scale-out — Windows Server can't do these

Proof Points:

  • Per-CAL costs at scale vs flat Fusion licensing
  • Fusion runs in containers and on ARM — Windows Server does not
  • OS footprint: Fusion 32MB min vs Windows Server 512MB min

"Your pricing is too high"

What They Really Mean: They haven't connected the price to the value, or they're comparing to free/included alternatives.

Response Framework:

  1. Anchor on value, not cost — what does downtime or slow file access cost them per hour?
  2. Compare to the real alternative cost: Windows Server CALs + hardware, or Samba + engineering time
  3. Offer an evaluation to let the performance speak for itself

Proof Points:

  • [ROI calculator or TCO model — Sales/PMM]
  • Real customer: 11 Samba nodes consolidated to 4 Fusion nodes — significant TCO reduction in heat, power, switch ports, OpEx
  • [Evaluation process details — Sales]

Strategic & Adoption Objections

"We're a Microsoft shop"

What They Really Mean: Strategic alignment with Windows Server, or perceived integration risk with Linux.

Response Framework:

  1. Are you really, though? Most enterprises have Linux running application workloads alongside Windows
  2. Fusion SMB beats Windows Server at its own game — better security, scale, performance, with the full Windows SMB feature set
  3. Native AD integration, Kerberos, Windows ACLs, and ABE (which Microsoft itself recommends not enabling on Windows due to performance issues — Fusion handles it correctly)
  4. No compromise — you simply get a better version of Microsoft's own product

Proof Points:

  • Full AD, Kerberos, Windows ACL, ABE — same admin experience as Windows
  • Microsoft notes ABE has poor performance on Windows Server; Fusion implements it efficiently
  • Fusion supports containers and ARM; Windows Server supports neither
  • OS overhead: Fusion 32MB / 1GB recommended vs Windows Server 512MB / 4GB
  • Head-to-head IO benchmarks (Linux+Fusion vs Windows Server 2025): Fusion wins on every IO size and pattern. Large IO 1M sequential read: Fusion 22.5 GB/s vs Windows 15 GB/s. Small IO 64K random write: Fusion ~2 GB/s vs Windows ~1.2 GB/s. Latency: Fusion consistently ~0.5–0.8 ms vs Windows ~0.8–1.2 ms across the test matrix.
  • Container performance: Fusion in a container outperforms Samba or Windows Server running on the host — containerization isn't a tradeoff for Fusion

"Microsoft develops SMB — why use a third party?"

What They Really Mean: Why pick a third-party when the protocol owner sells the product?

Response Framework:

  1. Microsoft developed SMB, but Windows Server file serving is no longer Microsoft's strategic focus
  2. FY2025 saw Microsoft's first-ever decline in Windows Server quarterly revenues, with the company warning investors of continued declines
  3. There is no longer substantial work happening in the SMB protocol or the Windows file server as a scenario at Microsoft
  4. Fusion SMB continues to actively innovate the file server — that is our core business
  5. Tuxera's Enterprise Storage Technical Officer is the 12-year Microsoft architect of SMB 3 and creator of SMB compression and SMB over QUIC. The future of the SMB file server is at Tuxera

Proof Points:

  • Microsoft FY2025 Windows Server revenue decline — first ever
  • Active Tuxera roadmap: SMB compression, SMB over QUIC, multiple enhanced products under development
  • Tuxera's product leadership: former 12-year MS SMB 3 architect
Verify with PMM

The Microsoft FY2025 Windows Server revenue decline is sourced from the battlecard. Sales should confirm the public source/citation before referencing in customer conversations.


"We're not using containers or Kubernetes"

What They Really Mean: Their infrastructure doesn't currently rely on container orchestration.

Response Framework:

  1. Reframe: not yet?
  2. 93% of companies use Kubernetes in production, are piloting it, or are evaluating it (Linux Foundation data)
  3. Enterprise software is moving to microservices and containers — and a Windows file server simply cannot run in a container
  4. Fusion SMB's multi-threaded user-mode architecture is ideal for containerized SMB servers within Kubernetes, via the Container Storage Interface
  5. Future-proofs your file serving for the inevitable container transition

Proof Points:

  • 93% Kubernetes adoption/evaluation per Linux Foundation
  • Fusion SMB runs natively in containers and Kubernetes
  • Windows Server file server cannot run in a container — Microsoft architectural limitation
  • Container Storage Interface (CSI) integration
  • Zero performance penalty: in robocopy throughput tests, Fusion-in-a-container (~608 MB/s) actually beats Samba-on-the-host (~588 MB/s) and Windows Server 2025 (~562 MB/s). Containers aren't a slow deployment option for Fusion — they're a first-class one

"We're not using ARM"

What They Really Mean: They're standardized on Intel/AMD or unfamiliar with ARM economics.

Response Framework:

  1. Ask: is that because you don't want to, or because you can't?
  2. Windows Server cannot run on ARM — period
  3. ARM offers significant energy, heat, and cost savings — increasingly relevant for HPC and cloud (e.g. AWS Graviton)
  4. Fusion SMB runs on whatever Linux runs on, ARM included
  5. Future-proof for the ARM workloads coming to your fleet

Proof Points:

  • Windows Server: Intel/AMD only, no ARM support
  • AWS Graviton (ARM) is mainstream for cloud workloads
  • HPC environments increasingly ARM-based for energy efficiency
  • Fusion SMB fully supports ARM processors

Trust & Risk Objections

"Samba is open source — we trust it more"

What They Really Mean: They equate open source with safety, or don't understand GPLv3 implications for commercial use.

Response Framework:

  1. Acknowledge open-source value generally
  2. Highlight Samba's specific risk: the GPLv3 license
  3. Mixing GPLv3 code with proprietary components creates legal risk for products you distribute to customers
  4. Most of the open-source community — including the Linux kernel itself — avoided GPLv3 in favor of permissive licenses
  5. Fusion SMB ships under commercial terms tailored to your business with no legal risks

Proof Points:

  • GPLv3 is a known issue for products that distribute Samba commercially
  • The Linux kernel itself rejected GPLv3 — Samba is one of few enterprise-relevant projects still on it
  • Commercial license eliminates legal review burden in procurement

"Samba is proven 1990s technology"

What They Really Mean: Long-standing software is more trustworthy.

Response Framework:

  1. Reframe: Samba is proven... for 1990s-style workloads
  2. It's process-based instead of threaded — an architectural bottleneck that prevents enterprise-scale performance
  3. Heavy on processor and memory under substantial workloads — that's why it works fine in small businesses but not enterprises
  4. Fusion SMB isn't brand new either — it's been used in high-end storage platforms since 2016
  5. Modern multi-threaded service with full support for 21st-century technologies: RDMA, SDS in scale-out clusters, compression

Proof Points:

  • Samba: process-per-connection (single-threaded performance per connection)
  • Fusion: multi-threaded, designed for modern hardware
  • Production deployments since 2016 in enterprise storage platforms
  • Active feature development; Samba's pace has slowed

"Samba runs on millions of servers"

What They Really Mean: Volume = trust, or "if it's that common, it must be good enough."

Response Framework:

  1. Yes — millions of low-end servers and consumer NAS appliances you'll find at Best Buy
  2. Those workloads are very different from yours
  3. Fusion SMB was designed for critical workloads, high performance, and both extremes — very small embedded and very large scale-out
  4. Match the tool to the workload class

Proof Points:

  • Samba's typical deployment: small businesses, consumer NAS, low-end NAS appliances
  • Fusion's typical deployment: enterprise storage platforms, performance-critical environments
  • Different workload classes require different software

"We're not worried about patent protection"

What They Really Mean: They haven't considered Microsoft IP exposure, or assume Samba's longevity = legal safety.

Response Framework:

  1. They should be — SMB is a Microsoft-developed protocol with significant IP
  2. Samba operates without a Microsoft SMB patent license; it exists in a risky legal area where the community simply hopes Microsoft does not pursue litigation for its significant IP
  3. This is a real legal risk — particularly for organizations distributing storage products commercially
  4. Fusion SMB commercial licenses include full Microsoft SMB patent protection — no IP exposure

Proof Points:

  • Tuxera is an official Microsoft SMB technology partner and patent licensee
  • Samba relies on Microsoft choosing not to enforce SMB patents
  • Patent indemnification is critical for OEM/redistribution scenarios

"We can do our own support"

What They Really Mean: They have Linux/Samba expertise in-house and want to avoid third-party costs.

Response Framework:

  1. Internal expertise is valuable for everyday operations
  2. The question is: when production storage is down at 3 in the morning, you can't be asking a web forum for guidance
  3. Fusion has 24x7 global support with expert engineers directly backed by the actual developers of the code
  4. Tuxera's Enterprise Storage Technical Officer — Ned Pyle — spent 20 years at Microsoft as the designer of SMB 3 and the owner of NFS 4. There is literally no deeper combined expertise in SMB and NFS available anywhere in the industry
  5. Position vendor support as insurance, not redundancy

Proof Points:

  • 24x7 global support with engineering escalation
  • Direct access to developers — not outsourced tier 1
  • Tuxera's protocol expertise: Ned Pyle (former 20-year MS designer of SMB 3 and owner of NFS 4) is now Tuxera's ESTO and product owner of both Fusion SMB and Fusion NFS — uniquely valuable for organizations running both protocols
  • Global offices: Helsinki (HQ), Seattle, Budapest, China

"We've never heard of Tuxera"

What They Really Mean: They need reassurance about vendor stability and credibility.

Response Framework:

  1. Tuxera is an official Microsoft SMB technology partner and patent licensee
  2. Tuxera's file system technology ships in billions of devices (cars, cameras, consumer electronics)
  3. Global support footprint: Helsinki HQ, Seattle, Budapest, China (opening Dec '25)
  4. Tuxera's Enterprise Storage Technical Officer is Ned Pyle — 20 years at Microsoft as the designer of SMB 3 and owner of NFS 4 — now product owner of both Fusion SMB and Fusion NFS
  5. Tuxera has been in enterprise SMB since 2016 and is the partner behind IBM Storage Scale's next-generation protocol nodes
  6. Customer references include Data in Science Technologies (DST) and IBM Storage Scale deployments

Proof Points:

  • Microsoft partnership and patent license
  • Global office presence
  • DST testimonial: "Tuxera Fusion SMB represents the next generation of data infrastructure for high-performance computing environments." — Andrew E. Gauzza III, CEO, Data in Science Technologies
  • [Additional named customer references — PMM]

"What if Tuxera goes away?"

What They Really Mean: Vendor risk is a real concern for infrastructure software.

Response Framework:

  1. Address directly — Tuxera has been in business since [year — PMM], profitably
  2. Escrow or source code access arrangements (if available)
  3. Standard industry protocols — SMB is an open standard, not a proprietary lock-in
  4. Migration path always exists — but unlike a Samba forklift, you'd be migrating from a working high-performance solution

Proof Points:

  • [Company longevity and financial stability data — PMM]
  • [Escrow or continuity arrangements — Legal/Sales]
  • SMB protocol is open and standardized

"We need to evaluate before committing"

What They Really Mean: This is a buying signal, not an objection.

Response Framework:

  1. Agree enthusiastically — Fusion SMB wins on evaluation
  2. Offer structured evaluation: see Pre-Sales Demo Environment Guide
  3. Provide POC support and success criteria framework

Proof Points:

  • [Evaluation win rate data — Sales]
  • [Evaluation support commitment — Sales]

Adding New Objections

When you encounter a new objection in the field:

  1. Document the objection, context, and what response worked (or didn't)
  2. Submit as a PR or send to [Sales/PMM owner TBD]
  3. Include the customer segment and deal stage for context

Action Required

Sales/PMM — Please validate these responses with field experience and add objections from real sales conversations. The most valuable additions are objections where we've lost deals and refined our response. Contact: [Sales/PMM owner TBD]

Knowledge Check
1. When a prospect says 'Samba is free', what is the strongest counter-argument?
2. How should you respond to 'We've never heard of Tuxera'?
3. When a prospect says 'We need to evaluate before committing', how should you interpret this?
4. How should you handle 'We're a Microsoft shop'?
5. How should you respond to 'We're not worried about patent protection'?