Release Announcements ===================== This is the first release candidate of Samba 4.25. This is *not* intended for production environments and is designed for testing purposes only. Please report any defects via the Samba bug reporting system at https://bugzilla.samba.org/. Samba 4.25 will be the next version of the Samba suite. UPGRADING ========= NEW FEATURES/CHANGES ==================== SMB3 Persistent Handles (Experimental) -------------------------------------- Samba now includes experimental support for SMB3 Persistent Handles, a fundamental building block for Transparent Failover. Persistent Handles allow SMB clients to reconnect after a server restart or outage while retaining valid file handles. Samba persists all necessary handle state to durable on-disk storage so that open files can be reconstructed when clients reconnect. This enables applications that depend on uninterrupted file access, such as virtual machine storage and clustered database workloads, to tolerate temporary server failures without having to reopen files. Persistent Handles are advertised through the SMB3 protocol capability SMB2_CAP_PERSISTENT_HANDLES. To make use of them on a share, both the global "smb3 persistent handles" option and the per-share "continuous availability" option must be enabled. Because Persistent Handles require Samba to maintain SMB state, they are only available on shares configured for SMB-exclusive access. Specifically, they require: kernel oplocks = no kernel share modes = no posix locking = no These settings disable interoperability with local POSIX file access and NFS clients on the affected share. Administrators should be aware that Persistent Handles incur a significant performance cost. File handle metadata is synchronously persisted to durable storage for every open, update, lease, and close operation, increasing latency compared to traditional SMB file serving. For this reason, the feature is intended only for workloads that require Continuous Availability semantics and is not recommended for general-purpose file servers. This feature is currently considered experimental. Cluster-wide rate limiting in vfs_aio_ratelimit ------------------------------------------------ The vfs_aio_ratelimit VFS module has been extended with cluster-wide coordination. When Samba clustering is enabled, the configured per-share rate limits are now enforced as a global ceiling across the entire cluster rather than per-node. Each share's limits are tracked and enforced independently. Coordination is handled by a new per-node daemon, ratelimitd, which aggregates activity from all smbd processes on the node and broadcasts node-level summaries to the rest of the cluster via Samba's messaging layer. To enable this feature, Samba must be built with --with-ratelimitd. JSON Audit logging ------------------ The two leading spaces before the opening '{' on JSON audit log lines have been removed. And any embedded new line characters '\n' are converted to spaces. Domain encryption types changed to AES by default ------------------------------------------------- The default value of the smb.conf option ‘kdc default domain supported enctypes’ now corresponds to ‘aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96’ (both AES encryption types) if the domain functional level is 2008 or higher. This addresses CVE-2026-20833. CTDB changes ------------ * CTDB's locations for locks, PID files and sockets now use ctdb/ subdirectories of the Samba locations configured at build time. This means that the relevant top-level Samba configure options (--with-lockdir, --with-piddir, --with-sockets-dir) are now also used by CTDB. The standalone CTDB build does not support these options. However, it is generally only used for developer/standalone testing. * The CTDB initscript (ctdb.init) has been moved to ctdb/doc/examples. This recognises that it isn't installed by default so it is basically unmaintained and untested. * Monitoring of (infrastructure) hosts is now supported. A good use of this is to monitor DNS servers. See the NETWORK MONITORING section in ctdb-script.options(5) for more details. * The detect_init_style() script function and associated CTDB_INIT_STYLE variable are deprecated, so will be removed in a future release. Use the new, more general CTDB_PLATFORM_STYLE variable instead. This may affect site-local CTDB (event) scripts. See ctdb.sysconfig(5) for more details. Cluster functional level ------------------------ Samba now maintains a cluster functional level, a cluster wide value that is kept as persistent global state and shared by all nodes. It is similar in spirit to the domain and forest functional levels known from Active Directory. The purpose of the functional level is to allow controlled upgrades of a cluster. New database formats, new internal messages and other changes that affect the communication between nodes are gated behind an explicit raise of the cluster functional level. As long as the level has not been raised, all nodes keep writing and sending the old formats, so that nodes running different Samba versions can interoperate during a rolling upgrade. A level consists of a major and a minor number, e.g. "1.0". Samba 4.25 implements the initial level 1.0, which is currently also the only defined level. On a non-clustered server the highest supported level is always activated automatically, there is nothing to configure or maintain. On a cluster the currently active level is stored persistently in cluster_level.tdb. On a fresh cluster it is initialized with the highest level supported by the first node that starts up. From then on the level never changes on its own, it is only raised when an administrator explicitly asks for it. A node that does not support the currently active level refuses to start, which keeps a node running an incompatible Samba version from joining the cluster. Once all nodes of a cluster have been upgraded to a new Samba version, the administrator can raise the cluster functional level. The new 'net clusterlevel' subcommands are available for this: net clusterlevel features List the cluster functional levels supported by the installed binaries. net clusterlevel show Show the currently active cluster functional level. net clusterlevel showall Show the levels supported by each node of the cluster, together with the currently active level and the highest level that could be activated. net clusterlevel upgrade [--test] [--apply] Raise the active cluster functional level to the highest level supported by all nodes. With --test (the default) only checks and reports whether the upgrade would be possible, --apply performs the actual upgrade. Note that raising the cluster functional level is a one way operation, there is no way to lower it again. It should only be done once all nodes have been upgraded and the new version has proven to work. The current implementation is deliberately strict: an upgrade is only possible if all nodes announce the exact same set of supported levels, which in practice means that all nodes run the same Samba version. Also note that this change only prepares for the future. It is not designed help with upgrades from older versions before 4.25 to 4.25 as a target. However vendors are free to use their own backports and use custom levels >= 0.1 and < 1.0. REMOVED FEATURES ================ smb.conf changes ================ Parameter Name Description Default -------------- ----------- ------- allow dcerpc auth level connect deprecated kdc default domain supported enctypes New default AES encryption types (if supported by domain) KNOWN ISSUES ============ https://wiki.samba.org/index.php/Release_Planning_for_Samba_4.25#Release_blocking_bugs ####################################### Reporting bugs & Development Discussion ####################################### Please discuss this release on the samba-technical mailing list or by joining the #samba-technical:matrix.org matrix room, or #samba-technical IRC channel on irc.libera.chat If you do report problems then please try to send high quality feedback. If you don't provide vital information to help us track down the problem then you will probably be ignored. All bug reports should be filed under the Samba 4.1 and newer product in the project's Bugzilla database (https://bugzilla.samba.org/). ====================================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ======================================================================