SMBLibrary: a user-mode SMB server and client for .NET

The problem: file sharing without a kernel driver or a Windows host

SMB is the protocol Windows uses for file shares, and it is also how a great deal of infrastructure talks to storage. The problem for a .NET developer is that the obvious ways to implement it are not all open and not all portable.

SMBLibrary is an open-source C# SMB 1.0 and CIFS, SMB 2.0, SMB 2.1 and SMB 3.0 server and client implementation. The stated purpose is to give .NET developers an easy way to share a directory, a file system or a virtual file system, or to connect to an existing share, with any operating system that supports the SMB protocol.

The word user-mode in the project description is the important qualifier, and it describes a design decision rather than a limitation. Nothing here is a kernel driver and nothing here depends on the Windows filesystem. The library is modular: you can take advantage of Integrated Windows Authentication and the Windows storage subsystem on a Windows host, or use the independent implementations that allow for cross-platform compatibility. So the same code can serve a share on Linux and on Windows, and on the Windows host it can additionally reuse the operating system's own authentication and storage plumbing.

The compatibility claim is specific: SMBLibrary can communicate with any Windows version since Windows NT 4.0. That is a statement about the range of peers it can talk to, and for a library whose users are often integrating with legacy appliances, it is the reason to look at this project in the first place.

The licence is LGPL-3.0, the primary language is C#, the last push was on 2026-09-20, and the published releases are v1.5.8 from 2026-09-14, v1.5.7 from 2026-04-17 and v1.5.6 from 2026-02-27.

The two transports, and the three differences between them

SMBLibrary supports two transport methods, and the documentation is unusually precise about how they relate.

NetBIOS over TCP uses port 139, and direct TCP hosting uses port 445. The documentation says the two are almost identical, and then lists the three differences, which is a useful piece of engineering honesty rather than a summary.

A session request packet is what initiates the NBT connection, so the NetBIOS layer has a handshake of its own before any SMB traffic. A keep alive packet is sent from time to time over NBT connections, which the direct path does not need because the connection is already a TCP session with its own keepalive. And for SMB2, direct TCP hosting supports large MTUs.

The third point is the one that decides which transport you use. Large MTU support matters for bulk transfers, and it is a property of the framing rather than of the protocol above it, so it is available on the direct path and not on the NetBIOS one.

The practical consequence is that direct TCP hosting on port 445 is the default choice for a new deployment, with NetBIOS over TCP kept for the peers that cannot do anything else. It is also the transport that modern networks block by default, which is a fact about firewalls rather than about this library, but it is worth knowing before you deploy.

The two supporting documents in the repository are the ones to read for the details: ServerNotes.md for the server side and ClientExamples.md for the client side.

The package split: cross-platform, Windows specific, and the filesystem adapter

Three NuGet packages come out of this repository, and the split tells you how the library is meant to be consumed.

SMBLibrary is the cross-platform server and client implementation, and it is the one you install if you are building a server on Linux or connecting to a share from a .NET service that is not on Windows. It is the whole of the protocol work and it depends on nothing platform specific.

SMBLibrary.Win32 is the package that allows utilizing Integrated Windows Authentication and/or the Windows storage subsystem on a Windows host. That is the piece that makes the modularity claim real: on Windows, the same server code can delegate authentication to the operating system instead of managing credentials itself, and can serve the native filesystem rather than a managed one. The authentication side matters for an Active Directory joined server, because the client can then use the credentials it already has.

SMBLibrary.Adapters is the smallest of the three, an IFileSystem to INTFileStore adapter for SMBLibrary. Its existence tells you something about the design: the library's internal file store interface is separated from the file system abstraction, and the adapter is what lets a caller hand a .NET file system implementation to the SMB server side. That is how the virtual file system case in the project description works, where the shared thing is not a directory on disk but something your code provides.

So the packaging is a deliberate three way split: protocol in the core, platform integration on the side, and the bridge between the library's storage model and .NET's file system model in the adapters package.

Serving a share and consuming one, from the same codebase

Because the implementation covers both roles, the same library handles the two halves of a typical integration, and the documentation keeps the two sets of guidance separate with ServerNotes.md and ClientExamples.md.

On the server side, the point of the library is that the thing you share does not have to be a directory. The project description names a directory, a file system or a virtual file system, and the adapters package is the mechanism for the last of those. That is the scenario where SMBLibrary earns its keep: exposing a database, an object store or an application API as a drive letter over SMB, without writing a driver and without a Windows machine.

On the client side, the library is how a .NET application talks to a share, whether that share is on a Windows server, a NAS, or a Samba box, and the transport and dialect negotiation is handled by the same code that implements the server.

The two roles together are what make the interoperability claim useful. A .NET service can expose a share that a Linux client mounts, and a .NET client can read a share that a legacy appliance writes, with the same library handling both ends.

The one caveat to hold in mind is the protocol range. The documented support is SMB 1.0 and CIFS through SMB 3.0, and there is no mention of the later revisions of the 3.x family in the project description, so a peer that requires newer dialect negotiation is not covered by what is documented here. The reverse is also worth thinking about: enabling SMB 1.0 and CIFS support in a network-facing deployment is a decision to take deliberately, because the protocol predates the mitigations that later revisions added.

The licence: LGPL, a paid alternative, and an assignment clause

The licensing is the part of this project that needs reading carefully, and there are three separate things in it.

The library itself is LGPL-3.0, and the licence text is in License.txt at the root of the repository. The project also states that a commercial license of SMBLibrary is available for a fee, and explains who it is for: companies who are unable to use the LGPL version, with a request to contact the author for additional details. So there is a route for organisations whose legal or procurement process cannot accept LGPL, and it costs money.

The third element is the contribution clause, and it is stricter than a typical open source contribution agreement. If you choose to make a contribution to this project, you must agree to irrevocably assign to SMBLibrary and/or Tal Aloni all worldwide copyright and intellectual property rights in and to your contribution, effective upon submission.

That is a copyright assignment rather than a permissive licence grant, and it is worth weighing before anyone opens a pull request. It means the contribution does not stay under the same terms as the surrounding project, and it is a different bargain from the one most contributors to an LGPL project expect. If you are planning to contribute, that clause is the thing to read twice, and if you contribute on behalf of an employer, it is a question for whoever owns that policy.

Contact for any of this is the maintainer, Tal Aloni, with the address given in the project description.

The codebase, the test project and the shape of the repository

The repository layout is organised around the three packages and a sample server, and the directory names map directly onto the NuGet packages: SMBLibrary/ for the core, SMBLibrary.Win32/ for the Windows integration, SMBLibrary.Adapters/ for the file system bridge, and SMBServer/ as a host application, with SMBServer.sln as the solution that ties them together.

There is a test project, SMBLibrary.Tests/, which is the part of the layout that matters most for an adopter of a protocol library. An SMB implementation is a large surface of state machines, and the only way to trust a client against a variety of peers is to have a server to test against, which is why the server is in the same repository and not in a separate project.

The Utilities/ directory holds supporting tools, and the two Markdown documents at the root, ClientExamples.md and ServerNotes.md, are the user-facing documentation. There is also a Readme.md, a .gitattributes and a .gitignore, and the absence of a large documentation site is consistent with a project whose documentation is two notes files and a couple of example documents.

The recent release cadence, with three releases between February and September 2026, and the last push on 2026-09-20, indicate a project that is still being worked on. For a protocol library used in production infrastructure, that matters, and the 1.5.x line has been stable enough to have had three patch releases in seven months.

Where SMBLibrary is the wrong tool

The boundaries are mostly about protocol coverage and about the terms rather than about the code.

If your peer speaks only the later revisions of the 3.x family, the documented support stops at SMB 3.0, and no amount of testing in this repository will change that. If you need features outside the SMB protocol itself, such as encryption or signing policies that a modern client requires, this library does not claim them.

If your organisation cannot use the LGPL build and does not want to buy a commercial licence, there is no third path in the licensing terms.

And if your project needs something that SMB does not do, the honest framing is that this is a protocol implementation, not a file server product. It has no share management, no quota accounting, no audit trail and no user interface, and the sample server in the repository is there so you can test a client, not so you can deploy it.

Where it is the right tool is narrower and clearer. If you are on .NET and need an SMB server on a platform that does not have one, especially one that shares something other than a directory, this library is one of the few options that lets you stay in user mode and in C#. That is a real gap in the ecosystem, and the project fills it, with the caveats above and a maintainer you can email.

Editorial conclusion

Adopt SMBLibrary if you need to serve or consume SMB shares from .NET on a platform other than Windows, or if you want to expose a virtual file system over SMB without writing a kernel driver, and if the LGPL terms work for you. Do not adopt it if you need SMB 3.1.1 features, since the documented range stops at SMB 3.0, and do not adopt it if your organisation cannot use the LGPL build and is unwilling to buy the commercial licence. Before you commit, read the licensing section and the contribution terms, and check the client examples and server notes, which are the two documents that tell you what the library actually does.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. TalAloni/SMBLibrary on GitHub