Samba: three decades of SMB interoperability, and a mirror that is not the source

What the suite actually does

Samba is described as the standard Windows interoperability suite of programs for Linux and Unix, and the README says that since 1992 it has provided secure, stable and fast file and print services for all clients using the SMB/CIFS protocol, naming all versions of DOS and Windows, OS/2, Linux and many others. The second half of the README is about identity rather than files, and it is the half that matters in a corporate deployment. Samba is an important component for integrating Linux and Unix servers and desktops into Active Directory environments, and it can function both as a domain controller and as a regular domain member. A full HOWTO is provided for the Active Directory domain controller implementation, and separate community guidelines exist under the title of how to do Samba nicely, which tells you that the project treats its own community as something to be managed deliberately rather than left to chance.

The GitHub repository is a mirror, and that changes how you contribute

The repository description is the first line of defence and it is unambiguous. The GitLab repository is the official mirror of the one on git.samba.org, and merge requests should be made on GitLab, not on GitHub. The README repeats it, pointing at the GitLab mirror and at a wiki page with step by step instructions for submitting a patch via GitLab. The reasoning is about a single upstream with one review path, and the mirror exists for people who read GitHub rather than for people who send patches. The rest of the contribution guidance is unusually human. The README points at the team page for the people currently active in development, and it suggests that if you want a particular feature you should look through the git change-log on the web and see who added it and send them an email, which is advice from an era when a maintainer answered mail. The closing line of that section is the honest summary of open source maintenance, that free software of this kind lives or dies by the response we get, and that if nobody says they like it, the maintainers will probably move onto something else.

The build system is waf, and the test targets are the interesting part

The top level Makefile is a thin wrapper around waf, the build tool in `buildtools/bin/waf`, with a fixed Python hash seed and waf make mode, and every real target delegates to it. The set of targets is where the project's engineering culture shows. Beyond the basics of build, install, uninstall and test, there is a quick test target that runs the fast subset, a randomized test target that changes the order of the suite, a subunit test target for the fine grained assertions, a testenv target for running the tests in a controlled environment, a gdb testenv variant for debugging, a pep8 target for style, an etags and ctags target for navigation, a dist and distcheck pair for producing and verifying a release tarball, and a printversion target. There is also a coverage path documented in the file, which starts with configuring with coverage enabled and running the test suite before capturing with lcov and generating an HTML report. The continuous integration configuration is split across several GitLab pipeline files for different runner classes, and the tree also carries a Coverity configuration and a gitleaks configuration, so static analysis and secret scanning are part of the routine rather than an occasional exercise.

A subsystem layout that shows the scope of the thing

The top level directories are a map of what Samba does. There are the server components, with `auth/` for authentication, `file_server/` for the share layer, `dfs_server/` for distributed namespace support, `dynconfig/` for runtime configuration, `libds/` for the directory services and Active Directory client libraries, `librpc/` for the RPC layer, `libcli/` for the client library, `libgpo/` for group policy, `nsswitch/` for the name service switch integration, and `ctdb/` for the cluster database. The build machinery sits in `buildtools/`, `bootstrap/` and `script/`, the packaging work in `packaging/`, and the idl compiler in `pidl/`. Two directories show where the project is heading, since `python/` and `rust/` sit next to the C sources. There is also `docs-xml/`, a `VERSION` file, a `WHATSNEW.txt` that records what changed, and a `PFIF.txt` alongside a `VFS-License-clarification.txt`, which is a detail worth noticing. Projects that vendor a small part of Samba occasionally trip over unclear licensing of individual files, and Samba ships explicit clarification files rather than leaving that to guesswork.

Licence, governance and the question of who owns it

Samba is free software licensed under the GNU General Public License, and the README says the Samba project is a member of the Software Freedom Conservancy, which is the legal structure that holds the project's assets. The distributability statement is the standard one, that the software is freely distributable under the GNU public license and that a copy of the licence should have been received with the software in a file called COPYING, and that file is indeed in the repository. The licence question is more involved than one file, because Samba aggregates code from many sources, which is why the tree carries the per-file clarification files, and because the samba.org website, the wiki, the mailing list archives and the git history are all part of what the project maintains. The repository also carries a SECURITY.md and a `.gitleaks.toml`, and the `WHATSNEW.txt` file is the release-notes surface that a user reads after an upgrade.

Documentation, mailing lists and how to ask a question well

The documentation section says there is quite a bit of documentation included with the package, including man pages and the wiki, and it asks for help with the documentation, saying the project is moving as much content there as possible. The mailing list section is where the README gets unusually detailed, and the etiquette list is worth reading as a piece of community engineering. Subject lines should be short and descriptive and should avoid the words help and Samba, since the readers already know both, with the examples given being a slow response with Excel files and migrating from Samba PDC to NT PDC. Replies should quote only the relevant lines and trim the headers, and the list does not want to argue about spam filters. Two rules stand out. Never say me too, because it does not help anyone solve the problem, and if you are having the same problem, give more information than the other writer has. And if you ask about a problem, come up with the solution yourself and post it, because someone else may have it and never hear the answer. Reporting a problem means giving as much relevant information as possible, such as the Samba release number, the operating system and the kernel version, and the last line of the list is two words long.

Where the project stands now

The repository is a large C code base with a GPL licence, the default branch is master, and the last push to it was on 2026-10-15, so the mirror is being kept current. There are no GitHub releases, which is consistent with a project that announces versions on its own announcement mailing list, where every announcement also goes to the main samba list so subscribers only need one. The primary sources are the GitLab repository, where patches are reviewed, the wiki, which holds both the domain controller HOWTO and the community guidelines, the team page, and the mailing list archives that the website makes searchable. For anyone using Samba rather than developing it, the practical sources are the distribution packages, the man pages and the wiki, and the git change-log is a surprisingly good way to find out whether a behaviour you are fighting was a deliberate decision or a regression.

Editorial conclusion

Adopt Samba when you need Windows clients to talk to Linux or Unix file and print shares, or when you need a Linux server to join or run an Active Directory environment, and use the packaged builds rather than compiling it yourself unless you have a reason. Do not contribute to the GitHub repository, since the README says merge requests should be made on GitLab and the GitHub tree is a mirror, which is the one detail that will waste a contributor's afternoon if you miss it. Before you file a question on a Samba list, read the etiquette section, because the expectations for a useful report are explicit, and read the version and operating system requirements into your report, since the maintainers ask for them every time. The licence is GPL, the last push was on 2026-10-15, and the project is a member of the Software Freedom Conservancy.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. samba-team/samba on GitHub