Skip to main content
⏲Estimated time: 15 minutes
Learning Objectives
  • Diagnose and resolve the Windows 11 24H2 SMB signing performance issue
  • Troubleshoot trusted domain authentication failures
  • Identify the correct AD trust type affecting authentication behavior
  • Guide a customer through a scale-out cluster rolling upgrade without downtime or rollback loss
⚠
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.

Common Issues

This page documents known issues encountered in Fusion SMB deployments along with their causes and solutions. Use this as a quick-reference during support cases.

Windows 11 / Server 2025 Performance Degradation​

Symptom​

When connecting from Windows 11 24H2 or Windows Server 2025 clients, file transfer performance is significantly lower than when connecting from Windows 10 or Windows Server 2022 to the same Fusion SMB server with identical workloads.

Cause​

Starting with Windows 11 24H2 and Windows Server 2025 (shipped Autumn 2024), Microsoft changed the default SMB signing setting to always require signing. This was a departure from the previous 30 years of Windows defaults. SMB signing adds cryptographic overhead to every packet, which degrades throughput — this is expected behavior.

Solution​

Check the server's crypto thread count first. Fusion SMB processes cryptographic work — including SMB signing and signature verification — on a dedicated pool of crypto threads, sized by the crypto_threads global parameter. That parameter defaults to 1, so on a busy multi-core server the signing that Windows 11 24H2 and Server 2025 now require is serialized onto a single thread, throttling throughput.

Preferred: raise crypto_threads on the server

Set crypto_threads to match the number of logical cores on the host, in the [global] section of tsmb.conf:

[global]
. . .
# Match the number of logical cores available on the host
crypto_threads = 16
. . .
[/global]

crypto_threads is not exposed as a tsmb-cfg flag, so this is a configuration-file change and requires a server restart to take effect. This keeps signing enabled — preserving its security benefit — while recovering throughput lost to single-threaded signing.

Alternative: disable SMB signing on the client

If signing is not required by the customer's threat model, it can be disabled on the Windows client via Group Policy:

  1. Open Group Policy Editor (gpedit.msc)
  2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
  3. Set Microsoft network client: Digitally sign communications (always) to Disabled

No reboot is required, but the client must disconnect and reconnect to the Fusion SMB server. No changes are needed on the Fusion SMB server side.

Security Consideration

SMB signing prevents relay and tampering attacks. Treat disabling it as the fallback, not the opening move — raise crypto_threads first and re-measure. If signing is still disabled after that, evaluate the threat model and confirm the customer accepts the reduced security posture.

Verify with Pre-Sales / PM

Which release first offloaded signing to the crypto thread pool is not stated in the published documentation — a draft KB revision attributes it to 3025.4, but that has not shipped to docs.tuxera.com yet. Confirm the version before telling a customer that upgrading alone will fix signing throughput.

References​

Trusted Domain Authentication Issues​

Symptom​

Users from a trusted Active Directory domain cannot authenticate to Fusion SMB, or SID-to-UID resolution fails for accounts from trusted domains.

Cause​

Fusion SMB supports all AD trust types (parent-child, tree-root, shortcut, realm, forest, external), but whether a domain is "trusted" depends entirely on the Active Directory configuration — Fusion SMB respects whatever trust relationships AD reports. Issues typically arise when:

  • The trust relationship is misconfigured or has expired in AD
  • DNS resolution between domains is broken
  • Domain controllers for the trusted domain are unreachable
  • The trust is non-transitive (e.g., external trust) and the user's domain is beyond the trust boundary

Solution​

  1. Verify the trust in AD: Use Active Directory tools to confirm the trust is healthy and bi-directional (if required).
  2. Check DNS: Ensure the Fusion SMB server can resolve the trusted domain's DNS records, including SRV records for domain controllers.
  3. Check DC reachability: Verify that domain controllers for the trusted domain are reachable from the Fusion SMB server on the required ports (Kerberos 88, LDAP 389/636, SMB 445).
  4. Check Fusion SMB logs: Increase the log level and look for idmap messages related to the trusted domain. Run with log_level = 4 idmap:40 for detailed identity mapping logs.

AD Trust Types Reference​

Trust TypeTransitivityDirectionNotes
Parent-ChildTransitiveTwo-way onlyAutomatic within a forest
Tree-RootTransitiveTwo-way onlyLinks root domains in the same forest
ShortcutTransitiveOne-way or Two-wayOptimizes auth within a forest
RealmConfigurableOne-way or Two-wayConnects AD to non-Windows Kerberos
ForestTransitiveOne-way or Two-wayLinks two separate AD forests
ExternalNon-transitiveOne-way (default)Legacy/untrusted AD forest connections

References​

macOS Client Performance Issues​

Symptom​

macOS clients show significantly lower throughput than Windows clients connected to the same Fusion SMB server, or a single CPU core on the client is fully saturated while others remain idle during macOS file transfers.

Cause​

The macOS SMB client has two key limitations that affect performance:

  1. Multichannel requires multiple adapters — Unlike the Windows SMB client (which creates multiple TCP connections over a single NIC), the macOS SMB client only creates one TCP connection per adapter. This means a MacBook with a single Ethernet/Thunderbolt adapter gets one TCP connection, bottlenecking on a single CPU core.
  2. Zero-copy read interaction — In some macOS workloads, the default zero-copy read path (using sendfile) performs worse than the standard buffered read path.

Quick Diagnostic​

Check CPU utilization on the client: if one core is maxed out while others are idle, the client is likely not using multichannel — this is normal for single-adapter macOS clients.

Solution​

  1. For throughput — If the macOS client has multiple network adapters (e.g., wired + wireless, or multiple NICs), multichannel will engage automatically. Otherwise, single-adapter macOS clients are limited to single-connection throughput.
  2. For zero-copy — Test disabling vfs_zerocopy_read on the share serving macOS clients: 
    [share]
        netname = MacShare
        vfs_zerocopy_read = false
    Benchmark before and after to confirm improvement.
Verify with Pre-Sales / PM

macOS limitations are from partner training sessions (Aaron Kennedy, Sep 2023). Tuxera is working with Apple on improving macOS multichannel support. Confirm current status before communicating to partners.

Cluster Rolling Upgrade Failures​

Symptom​

During a scale-out cluster upgrade, nodes fail to rejoin the cluster, continuous availability (CA) handles are lost, quorum breaks, or a node cannot be rolled back to its previous version.

Cause​

Scale-out cluster upgrades have three requirements that are easy to miss:

  1. Upgrade floor — clusters on any version prior to 3025.4.1 must be upgraded to 3025.4.1 first. Jumping straight to a later release from an older cluster is not supported.
  2. CA path during the upgrade — as of 3025.4.1 a fully upgraded cluster uses an in-memory distributed database and no longer needs the path parameter in ca_params. But during the rolling upgrade the path must remain configured, for backward compatibility with nodes still on the older software.
  3. Node ordering — the node with the lowest Node ID must be upgraded last.

Solution​

Before starting, confirm the CA path is configured:

ca = true
ca_params = path=/path_to_file_system_open_db_storage

Or the equivalent global option:

ca_path = /path_to_file_system_open_db_storage

Identify node IDs on any cluster node:

sudo corosync-quorumtool

The node with the lowest Nodeid in the membership table is the one to upgrade last.

Upgrade each node in that order:

  1. Place the node in standby: pcs node standby <nodename>
  2. Swap the tsmb-server binaries to the new version
  3. Remove standby: pcs node unstandby <nodename>
  4. Verify the node rejoined and quorum is intact: sudo corosync-quorumtool

Do not proceed to the next node until the current one is confirmed healthy.

After all nodes are upgraded, remove the path parameter from ca_params (or remove the global ca_path). Leaving it configured forces the CA database onto shared storage instead of the in-memory distributed database introduced in 3025.4.1 — negating a performance improvement and adding operational complexity.

Rollback window closes

A node can be rolled back to its previous version only while at least one other node is still running the older version. Once every node has been upgraded, per-node rollback is no longer possible — rolling back then requires taking the entire cluster offline first.

References​

Additional Known Issues​

Content Gap

The Fusion SMB knowledge base currently contains three documented issues. As new issues are identified and documented, this section will expand. Common areas where issues surface include:

  • Connection failures — often related to firewall rules, SELinux policies, or SMB dialect mismatches
  • Permission problems — ACL mapping between Windows and POSIX permissions
  • Cluster failover issues — watchdog timing, shared storage connectivity
  • Performance variations — related to VFS tuning parameters, encryption overhead, or storage backend characteristics

For issues not covered here, check the full Fusion SMB Documentation or contact Tuxera Support.

✍Knowledge Check
1. What causes performance degradation with Windows 11 24H2 clients?
2. A Windows 11 24H2 client reports slow transfers. What should you check on the server first?
3. Where do you disable SMB signing on a Windows 11 client?
4. When a user from a trusted AD domain cannot authenticate, what should you check first?
5. In a scale-out cluster rolling upgrade, which node must be upgraded last?