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
Disable SMB signing on the Windows client. This can be done via Group Policy:
- Open Group Policy Editor (
gpedit.msc) - Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- 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.
SMB signing prevents relay and tampering attacks. Evaluate your threat model before disabling signing. Consider whether the performance gain justifies the reduced security posture for your environment.
Upcoming: Signing Thread Pool Offload
Tuxera is actively working to offload SMB signing operations to a dedicated thread pool (similar to the existing crypto, transport, and VFS thread pools). This will significantly improve signing performance by parallelizing the cryptographic overhead across multiple cores, reducing the throughput impact of enforced signing.
Signing thread pool offload was described as "coming very quickly" in partner training (May 2025). Confirm current release timeline and whether this has shipped in a recent release.
References
- Control SMB signing behavior — Microsoft Learn
- SMB security hardening in Windows Server 2025 & Windows 11 — Microsoft Community Hub
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
- Verify the trust in AD: Use Active Directory tools to confirm the trust is healthy and bi-directional (if required).
- Check DNS: Ensure the Fusion SMB server can resolve the trusted domain's DNS records, including SRV records for domain controllers.
- 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).
- Check Fusion SMB logs: Increase the log level and look for
idmapmessages related to the trusted domain. Run withlog_level = 4 idmap:40for detailed identity mapping logs.
AD Trust Types Reference
| Trust Type | Transitivity | Direction | Notes |
|---|---|---|---|
| Parent-Child | Transitive | Two-way only | Automatic within a forest |
| Tree-Root | Transitive | Two-way only | Links root domains in the same forest |
| Shortcut | Transitive | One-way or Two-way | Optimizes auth within a forest |
| Realm | Configurable | One-way or Two-way | Connects AD to non-Windows Kerberos |
| Forest | Transitive | One-way or Two-way | Links two separate AD forests |
| External | Non-transitive | One-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 server is fully saturated while others remain idle during macOS file transfers.
Cause
The macOS SMB client has two key limitations that affect performance:
- 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.
- 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 Fusion SMB server: 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
- 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.
- For zero-copy — Test disabling
vfs_zerocopy_readon the share serving macOS clients:Benchmark before and after to confirm improvement.[share]netname = MacSharevfs_zerocopy_read = false
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.
Additional Known Issues
The Fusion SMB knowledge base currently contains two 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.