STF Project Overview
SerNet GmbH in Germany has secured significant funding from the German Sovereign Tech Fund (STF) to advance the Samba project. Samba core developers will tackle 17 key milestones in six target groups aimed at enhancing Samba’s security, scalability, and functionality. This project report will be continuously updated.
The focus of the project is on areas like transparent failover, SMB3 UNIX extensions, and modern security protocols such as SMB over QUIC. These improvements are designed to ensure that Samba remains a robust and secure solution for organizations that rely on a sovereign IT infrastructure that is as independent as possible of proprietary software regimes, but including optimal interoperability.
Development work began as early as September 1, 2024 and is expected to be completed by the end of February 2026 for all milestones. Work results will be uploaded to the public Samba software repositories for public use immediately after the milestones and tests have been completed.
Milestones:
Milestone Group 1: Security Enhancements
Milestone Group 1: Security Enhancements
1.1 Security Enhancement: MS-NRPC Netlogon security hardening (ETA: 2024-11-03)
Upcoming Windows versions will have new features to protect the communication with domain controllers as well as between domain controllers. They will use kerberos instead of relying on custom crypto. Samba needs to implement these with their client and server aspects.
1.2 Security Enhancement: SID Filtering (ETA: 2025-01-28):
Security Identifier (SID) filtering in Active Directory is a security measure that restricts the use of SIDs from less trusted domains to prevent unauthorized access to resources in more trusted domains, especially in multi-domain forest environments with trust relationships. While this is mostly a domain controller feature, it's also important for domain members. User and device claims also need to be transformed at the security boundaries.Milestone Group 2: SMB3 Fileserver Features
Milestone Group 2: SMB3 Fileserver Features
The SMB protocol, originally developed by IBM, was significantly further developed by Microsoft. Even though the Samba team has been carrying out independent software development for the open source implementation under Linux since 1992, it is an important part of the team's task to ensure interoperability with the Microsoft implementation. The following two important milestones have been written down for this purpose.
2.1 Fileserver Feature: SMB3 Directory Leases (ETA: 2024-12-24)
Allow clients to establish leases on directories, enabling improved caching and reduced network overhead for operations involving directory metadata, which can enhance performance and responsiveness when working with shared files and folders. Also the data model to store the relevant meta data needs to be improved. This task includes research and testing against Windows, as well as writing tests.2.2 Fileserver Feature: Transparent Failover / Persistent Handles (ETA: 2025-12-24)
Allow for seamless and uninterrupted file access by transparently redirecting clients to an available server in the event of a server failure, ensuring data continuity and high availability. Build infrastructure in the fileserver to support the related protocol flags for directory leases. Also the data model to store the relevant meta data. This task includes research and testing against Windows, as well as writing tests. The team may provide a database layer with per record persistance in addition.Milestone Group 3: SMB3 UNIX Extensions
Milestone Group 3: SMB3 UNIX Extensions
Samba needs to provide enhanced support for interoperability between Windows and Unix-like operating systems, enabling better handling of Unix-specific file attributes, permissions, and symbolic links when accessing files and directories over a network. The linux kernel smb client will be the initial consumer, but in future others like MacOS clients may also implement it. For the linux kernel client it aims to provide semantics like a local filesystem.
3.1 SMB3 UNIX Extensions: Regression tests and server adjustments (ETA: 2025-03-07)
Regression tests and server adjustments are crucial for maintaining the stability and performance of Samba. Regression tests ensure that recent changes or updates in the codebase do not introduce new bugs or issues. Server adjustments involve fine-tuning server configurations to optimize performance, enhance security, and handle increased traffic loads. Together, these practices help ensure that the software runs smoothly and efficiently, providing a reliable experience for users.3.2: SMB3 UNIX Extensions: Write protocol documentation (ETA: 2026-02-27)
There are already prototypes for the protocol documentation, but they need to be completed. They should be in form similar to the existing SMB2/3 documentation from Microsoft and in most parts explain where the behaviour differs between clients with SMB3 UNIX Extensions and clients without them.3.3: SMB3 UNIX Extensions: Improve Linux desktop environments (ETA: 2025-06-21)
Development needs to be done to enhance the libsmbclient library provided by Samba and use it in Gnome VFS libsmbclient is used in the GNOME VFS as well as the corresponding KDE counterpart to access file systems exported by SMB servers. This libsmbclient must be extended to implement the smb3 unix extensions to provide a more seamless integration into Linux desktop environments.Milestone Group 4: io_uring support
Milestone Group 4: io_uring support
io_uring is a Linux kernel interface designed to improve asynchronous I/O operations, offering lower latencies and higher performance. It allows applications to submit multiple I/O requests in a single system call, reducing overhead and improving efficiency. Samba team will enhance performance with efficient and scalable I/O operations by using Linux io_uring.
4.1 io_uring support: Integrate io_uring vfs module (ETA: 2025-11-26)
Integrating the existing io_uring vfs module into the default io_uring should replace the custom userspace threadpool for async io and it should interact with preadv2(RWF_NOWAIT) for small io in order to keep the latency low in the optimal case.4.2 io_uring support: Integrate io_uring into the socket io path (ETA: 2025-12-19)
Currently raw sendmsg(MSG_DONTWAIT) and recvmsg(MSG_DONTWAIT) are used for socket io, which means the main thread cpu bound during the memcpy inside the kernel. With IORING_OP_SENDMSG/IORING_OP_RECVMSG we can delegate the memcpy into helper threads for large messages. With IORING_OP_SENDMSG_ZC we could even avoid the cost completely if the network stack supports it.4.3 io_uring support: Full zero copy with IORING_OP_SPLICE (ETA: 2026-02-21)
If no SMB signing is used (e.g. where clients are in an isolated network) maximal performance is desired. Currently we have support for sendfile() support in the direction to the client, but that may still blocks the main thread. With IORING_OP_SPLICE we are more flexible as the 2nd step via pipe is excplicit and allows better interaction with the typical message flow.Milestone Group 5: SMB over QUIC
Milestone Group 5: SMB over QUIC
QUIC introduces an alternative to the TCP network transport, providing secure, reliable connectivity to edge file servers over untrusted networks like the Internet, an "SMB VPN" for telecommuters, mobile device users, and high security organizations. The SMB protocol needs to support QUIC and this milestone is about this work.
5.1 SMB over QUIC: Generic support of the linux kernel driver (ETA: 2025-02-19)
In addition to tcp ports 445 and 139 Samba's smbd should also listen on QUIC port udp port 443. This builds on top of https://github.com/lxin/quic, which is a linux kernel QUIC driver with a small userspace library. We need to adjust some code that expects tcp/ip address and port ranges.
5.2: SMB over QUIC: Inject QUIC support into socket_wrapper (ETA: 2025-03-13)
For automated tests it's important to avoid real kernel sockets. socket_wrapper simulates tcp and udp sockets on top of unix domain sockets. We should allow socket wrapper to have additional plugins, and we could try to simulate the QUIC kernel interface using the userspace driver from https://github.com/ngtcp2/ngtcp25.3 SMB over QUIC: Native userspace quic driver (ETA: 2025-04-04)
Directly use the userspace quic driver from https://github.com/ngtcp2/ngtcp2 as fallback for older kernels in order to implement smb client side support.5.4 SMB over QUIC: SMB2_TRANSPORT_CAPABILITIES negotiation (ETA: 2025-08-23)
This allows a SMB client to avoid double encryption using TLS (injected by QUIC) for the transport and user level encryption using various aes flavours based on kerberos/ntlmssp authentication.Milestone Group 6: SMB direct
Milestone Group 6: SMB direct
The following milestones in this group are all about performance of the SMB protocol: Enable high-speed, low-latency data transfer by leveraging Remote Direct Memory Access (RDMA) technology for direct communication between client and server network adapters without involving the CPU, enhancing performance and efficiency.
6.1 SMB direct: SMB direct socket layer for the Linux kernel (ETA: 2025-08-11)
There is some smb direct support in the linux kernel already, but it's not exposed to userspace. Instead of having multiple implementation the code should be consolidated and be used within the kernel, but also be exported to userspace to that Samba's smbd, libsmbclient
can also use it.This will also make it possible to write regression and performance tests just for the smbdirect transport layer instead of relying on functional tests with SMB3 clients and servers.
6.2 SMB direct: SMB Direct support in smbd and smbclient (ETA: 2025-10-14)
The integration of SMB Direct support in smbd and smbclient - the server and client - would also mean we will be able to write perform regression tests. We will also implement signing and encryption for the raw data transfer.6.3 SMB direct: Add automated SMB Direct functional testing (ETA: 2026-02-28)
For automated tests it's important to avoid real kernel sockets. socket_wrapper simulates tcp and udp sockets on top of unix domain sockets. We will allow socket wrapper to have additional plugins, similar to QUIC we will simulate the SMB Direct kernel interface. If it turns out to be too complex to add to socket_wrapper, we will alternatively use network namespaces.