Hi Jay! Apologies again on accidentally deleting your account. I'm so glad you found your way back...

Ok so first up to give you some context, I'm no Samba expert. I haven't used Windows regularly for over 10 years so have no need for it myself. I do run a local Mediaserver (which is built on top of our Fileserver), but I don't use the Samba (Windows file sharing) component. Having said that, I am intimately familiar with TurnKey Linux (and it's basis; Debian), and do have some experience with Samba - after having been involved in development and maintenance of our Filserver (and derivatives, i.e. Torrentserver and Mediaserver) and Domain Controller appliances.

Regarding my earlier statement about using separate appliances for each role, it's been a while since I recall reading that and haven't ever really heard a clear explanation of why or what issues might occur. So I thought I'd double check on that and see what the current recommendation and rationale are.

It turns out, that I may have had some misunderstanding myself for some time. Even back in 2013, whilst the recommendation was to use separate Samba services for AD DC and Fileserver functions, it wasn't actually a hard "no". See this quote from Andrew Bartlett (lead Samba developer):

For smaller sites, where there is just one server, using the AD DC as the file server is perfectly fine and supported. It will work well.

For other (generally larger) sites, the knowledge that the file server and DC can be configured, upgraded and replicated independently will be far more important, and so follow our advise to separate these roles.

Although it should probably be noted, that it appears that using a single server for both roles, does have some limitations. From the Samba wiki FAQ

Can I Use the Samba AD DC as a Fileserver?

Whilst it is not recommended, yes you can, but you should be aware of its limitations, amongst which is that you cannot obtain the users Unix home directories or login shell from AD, you must use template lines in smb.conf

Or in even more detail on the Samba wiki 'set up AD DC' page:

Whilst the Samba AD DC is able to provide file shares, just like all other installation modes, the Samba team does not recommend using a DC as a file server for the following reasons:

• For anything but the smallest organizations, having more than one DC is a really good backup measure, and makes upgrades safer
• It encourages upgrades of the DC to also be upgrades of the host OS every year or two, because there isn't complex data to transition or other services involved.
• This means upgrades can be done by installing fresh, and replicating in the changes, which is better tested in Samba, gains new features and avoids a number of lingering data corruption risks.
• The DC and file-server have different points at which an organization would wish to upgrade. The needs for new features on the DC and file server come at different times. Currently the AD DC is evolving rapidly to gain features, whereas the fileserver, after over 20 years, is quite rightly more conservative.
• mandatory smb signing is enforced on the DC.

It goes on with some more details, so if you're interested, please be sure to read the rest.

Also FYI, if you'd like to reduce the friction a little, I'd recommend installing (from ISO) to a "proper" VM (rather than using an LXC container). It should certainly be possible to get it running under LXC (other users have reported that they have it working - e.g. on GitHub). However, one issue I suspect you'll hit is that on our DC appliance, all shared files are owned by a single 'samba' Linux user, with ACLs (access control lists) used to separate the files of individual Windows/Samba users. I'm not 100% sure whether LXC completely supports that (it's filesystem dependent and AFAIK controlled by the kernel).

That may actually be another reason why using a separate AD DC and Fileserver might be a good option (and might not work properly on LXC regardless)? Our Fileserver uses a different user management regime (which isn't supported by Samba in AD DC mode, but works well in LXC) - individual Linux users mapped to Windows users (i.e. so no ACLs required).

If you do want to persist running on LXC, then IIRC your AD needs to be a privileged container. It's also worth keeping in mind that whilst Samba itself should be ok in a privileged LXC, if you install anything additional, you may find that some services won't run by default in a privileged container (due to service hardening in Debian). That can be worked around, but may require manual adjustment of specific services.

So in summary, I suspect that the least friction will be if you either use:

• A single Domain Controller VM - with Samba filesharing configured; or
• 2 separate LXC containers, an AD DC and a Fileserver

Both options will require some manual config (either to enable filesharing on the AD DC; or join the domain from the Fileserver).

Sorry that isn't completely conclusive and it certainly isn't exhaustive, but hopefully it gives you some more insight and if nothing else, some leads for more research.

Please post back as I'd be really interested to hear which way you choose to go, why and how it all ends up going. In fact, if you take notes during your work, please do share them with us as I'm sure that they'll assist other users. In the meantime, please feel free to share any feedback you have (pain points, docs that are wrong, don't make sense, etc) and/or ask any other questions that come up.

One last point I'll make is that our current AD DC appliance is a little dated. The version of Samba included doesn't work with Windows 11 (apparently there are workarounds, but they have security implications). I am working on an updated release which hopefully should "just work", but I'm not sure when it will be ready.

Good luck! :)