Repository navigation
Add support for Samba AD Member Servers #177
Description
Activity
Additional background process vs supervisor mechanisms
- Running smbd and winbindd together is straightforward and does not require a supervisor.
- smbd can remain PID 1, while winbindd is started in the background.
- Process failures are handled via Docker healthchecks and container restarts, consistent with the existing image design.
Binaries installation
apk add --no-cache samba-winbind samba-winbind-clients krb5 # maybe: samba-common-tools
Additional commands incl. fail-fast-check (recommended: additional logging on fail-fast)
winbindd --foreground -d 1 &
sleep 1
wbinfo -p >/dev/null 2>&1 || exit 1Diagnostics / extended logging
ps aux | grep [w]inbindd || true
command -v wbinfo
wbinfo -t || true
wbinfo -u | head || trueFirst ideas for start-up checks
nslookup -type=SRV _kerberos._tcp.{domain-dns-name} || true
nslookup -type=SRV _ldap._tcp.{domain-dns-name} || trueFirst ideas for health checks
wbinfo -p >/dev/null 2>&1 || exit 1
wbinfo -t >/dev/null 2>&1 || exit 1Hi
I was planning on someday create a active directory enabled/domain supporting container.
but I don't have much time to do this in a manner that I'm statisfied with the quality.right now this container focues more on end users and small businesses.
I figured, once you took the windows AD pill, why not use a windows storage system which fit's into your setup.
and if you build one using samba, you're able to build the solution you need yourself and do not need a container like mine to reduce the complexity.so sounds good, maybe someday I will build a variant with winbind/domain joining/even AD emulation support - but right now it's not a priority for me
Same to me: lack of time ;-) For now, I kept my 2 samba member file servers as VM with regular Ubuntu. But if I find opportunity, I'm going to prepare a commit and you could review it?
either create your own fork, or maybe I'd merge it as a new variant - but I will not add it for the main container, as I currently have a huge user base and I need stability and a small container - winbind support is to special for a broader audience
thanks and kind regards
new variant
That is intention, too :-)
Provide an additional image variant (e.g. smbd-winbindd-latest)
Which name would you prefer for the new variant?
Proposal
full-latestorfull-a<alpine version>-s<samba version>- full version of this repo inclusive components required for running Active Directory (AD) member servers
- includes everything of main (smbd, avahi, wsdd2) and winbindd/krb5
- optional service can still be disabled using ENV variables
smbd-winbindd-latestorsmbd-winbindd-a<alpine version>-s<samba version>- this will only include smbd, my scripts and winbindd/krb5
- optional service can still be disabled using ENV variables
I wand to run my classic samba member server in a docker container.
Therefore, I configured ENV with
The issue starts with the point that no winbind binary is available in image.
Next things are related to private secrets file (usually at /var/lib/samba/private/secrets.ldb) and a missing domain join and/or persisting domain membership on a permanent volume.
It would be fantastic if you can provide with an extended image/solution for this.
Additional clarifications and proposal
Scope:
Proposed solution:
similar to existing variants like smbd-only or smbd-wsdd2.
Technical requirements for AD member operation:
In particular:
Idempotent startup behavior:
Diagnostics / low-cost preflight checks:
Secrets handling:
(to avoid plain-text secrets in environment variables).
This would enable a well-defined and commonly used Samba setup
(AD member file server) while keeping maintenance and support effort low,
as the image would still follow the existing release and build cadence.