Samba 4.25.0 ships with experimental SMB3 persistent handles, Ceph support, and cluster HA tooling
The first stable release of the 4.25 series brings the project's most ambitious high-availability features yet. The headline capability still comes with strings attached, though.
Samba 4.25.0 shipped September 24, 2026, opening the new 4.25 series with experimental SMB3 persistent handles, native support for exporting Ceph object storage over SMB, and a new cluster functional level meant to make rolling upgrades safe. AES encryption also becomes the default for domain authentication.
For a project that has spent years as the quiet open-source backstop for Windows file services, this is a moment where it reaches a bit further toward the enterprise.
Samba has long been the workhorse you don't think about. It implements the Server Message Block (SMB) protocol, Microsoft's networking standard for sharing files, printers, and namespaces. On a Linux or Unix box, it lets a server pretend to be a Windows file server: join an Active Directory domain, serve shares, enforce Windows-style access controls, and even run as a full domain controller. That is how it became the de facto way to run Windows-compatible file services on non-Windows hardware, usually for less money and more flexibility than a Windows Server license.
Here is a small oddity worth flagging. SMB is Microsoft's protocol, and the company has historically been remarkably quiet about it. Rarely a press release dissecting the finer points of the spec. Samba quietly fills that gap, implementing the details out in the open.
The versioning follows a predictable pattern. Even-numbered X.Y.0 releases are the feature track; long-term maintenance branches keep getting security patches for years afterward. 4.25.0 is feature track. It is aimed at new deployments and early adopters, not organizations that cannot move off a mature branch. Standard advice, then: read the release notes before upgrading.
The persistent-handle gamble
The flagship addition is experimental SMB3 persistent handles, which Samba describes as a fundamental building block for transparent failover. Traditional SMB loses a client's file handles on a server restart, forcing a reopen of everything. Persistent handles persist the state needed to reconstruct open files to durable storage, so a client can reconnect with handles still valid.
That matters most for workloads that cannot drop an open file. Virtual machine storage. Clustered databases. A mid-operation file reopen can corrupt data or crash the application.
It is experimental for good reason, and several caveats come along.
To use persistent handles on a share, you enable both the global persistent handles option and the per-share continuous availability option. It only runs on SMB-exclusive shares, which means disabling kernel oplocks, kernel share modes, and posix locking. That kills POSIX file access and NFS interop on that share by design.
There is also a genuine performance hit. Handle metadata gets synchronously persisted to durable storage on every open, update, lease, and close operation. More latency than traditional SMB.
Samba added a persistent handles durability option so you can pick where you land on the trade-off curve. The persistent state itself lives in a volatile CTDB database replicated to every node, plus a persistent backup. Only the backup lets handles survive an outage of every node simultaneously, but keeping it costs an extra cluster-wide transaction on every handle change.
Keep in mind that Samba is explicit here. This is only for workloads requiring Continuous Availability semantics, and it is not recommended for general-purpose file servers. Fair warning, and you would be wise to take it.
The more practical win, arguably, is the cluster functional level. It is a cluster-wide value kept as persistent global state, sharing the spirit of Active Directory's domain and forest functional levels. The point is pragmatic: controlled, rolling upgrades.
New database formats, new inter-node messages, other communication changes can be gated behind an explicit raise of the level. As long as it has not been raised, all nodes keep writing and sending the old formats, so nodes running different Samba versions can interoperate during a rolling upgrade.
One catch: raising the level is irreversible. Samba 4.25 implements only the initial level 1.0. The implementation is strict too, since an upgrade only proceeds if all nodes announce the exact same set of supported levels, which in practice means every node runs the same version. The team says the feature prepares for the future rather than helping you upgrade into 4.25 from an earlier release. Manage it with the net clusterlevel subcommands, and vendors can still roll their own backports between levels 0.1 and 1.0.
If you need cluster-wide rate limiting, the vfs_aio_ratelimit module now coordinates across the whole cluster instead of per node. A new daemon, ratelimitd, aggregates activity from all smbd processes on a node and broadcasts node-level summaries to the rest of the cluster through Samba's messaging layer. Enable it by building with --with-ratelimitd.
Samba 4.25 also introduces vfs_ceph_rgw, a VFS module using librgw to export Ceph Object Gateway buckets as SMB shares. You get a hierarchical view of the bucket's objects, served as files and folders over SMB with standard POSIX UIDs/GIDs and most basic file operations. Organizations already running Ceph now have a Windows-native path to that data without a separate client.
Two minor tweaks round out the pile. The two leading spaces before the opening brace on JSON audit lines are gone, and embedded newlines now convert to spaces. Both make automated parsing more reliable. Small stuff, but you will appreciate it at 3 a.m. when a parser would otherwise have choked.
A security-driven default
The change that is easiest to overlook is probably the one to pay attention to. The default for the kdc default domain supported enctypes option now covers both AES encryption types (aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96) whenever the domain functional level is 2008 or higher. Samba ties this to CVE-2026-20833, steering domain controller authentication traffic toward stronger encryption by default.
The CVE advisory page for 2026-20833 did not yet serve full details at time of writing, so the complete description and CVSS score are still pending. Keep an eye on Samba's security pages.
That AES change lands against a backdrop of intensifying scrutiny. The July 2026 coordinated releases patched a cluster of serious flaws: an authenticated LDAP domain-takeover (CVE-2026-58221), an LDAP Compare filter injection (CVE-2026-58222), CTDB protocol bounds-checking issues (CVE-2026-58224), and a batch of KDC and DNS denial-of-service vectors (CVE-2026-58216, CVE-2026-58218, CVE-2026-6949), including a DNS signing DoS via TKEY name-cache exhaustion.
For anyone still on an older branch, the model is clear. Feature releases open a new track; mature branches keep getting security updates. The sensible stopgap is the latest patched point release on your current branch. For the 4.24 line, that is 4.24.7.
The series also reshuffles several smb.conf parameters. persistent handles and continuous availability both default to no, while persistent handles durability defaults to full_outage. The kdc option now defaults to AES when the domain supports it. Meanwhile getwd cache is gone and allow dcerpc auth level connect is deprecated. Enabling persistent handles disables local POSIX and NFS interoperability on that share by design, so factor that in before you flip the switch.
Between the two release candidates and final, the team also fixed a spread of bugs, many tied to the new persistent-handle work and DNS handling. Ralph Boehme cleaned up persistent-handles documentation and database-layer bugs, plus a regression where smbstatus byte-range locks got broken. Stefan Metzmacher added a requirement that SMB3 session setup responses always be signed, and fixed a winbindd crash. Volker Lendecke and others finished the cleanup after the getwd cache removal.
Known issues live on Samba's release planning wiki page under release-blocking bugs. The team wants high-quality reports filed in Bugzilla under Samba 4.1 and newer, and discussion on the samba-technical mailing list or the #samba-technical Matrix/IRC channels.
Head here to the release notes and download link.
