matt wilkie's picture

Hello, I'm brand new to TKL and could use some direction to reduce my fumbling and confusion. Please help if you can :)

I'm looking to setup a home network for about 8 machines -- mostly Windows 7 and 10 with a linux mint laptop -- and a linux server to bind them all and in light reveal them. (this would be the role I hope TKL fills.)

I've installed the TKL Linux Containers app. There was network issue which I'll get into somwhere else, but it's working now. My most pressing question is: Now what? How do I add other TKL apps to the container? (namely Domain Controller and File Server) And then get them working together?

Or, am I going about this in a non-optimal way. Should I install linux, then Xen, and then put the Domain Controller and File Sharing TKL vm machines into that?


Jeremy Davis's picture

I am in the final stages of wrapping up the v15.0 release and newer versions of LXC, fileserver and domain controller are all in the build bucket awaiting publishing by my colleague Alon.

Having said that, you don't need to wait and the current v14.2 builds are definitely serviceable.

Which ever way you go, you'll likely find the LXC appliance usage docs quite handy. Note that there have been significant changes (I'd argue improvements) in v15.0 so if you persevere with v14.2, then use this link to the v14.2 docs instead.

Having said that, I suspect that you'll need to make some tweaks to get ACLs in the domain controller working properly within an LXC. Personally, I'd probably consider running that as a full VM (although it should totally be possible to get it fully working in a container).

Whilst I love LXC (and obviously TurnKey too), I must admit that personally I use Proxmox as a hyperviser. That allows the option to use LXC containers (you'll find the TurnKey LXC templates downloadable within the webUI) or KVM VMs (so you can even install Windows if you really wanted...).

With regards to the domain controller, beyond the most basics (i.e. the initial development and basic testing since), TBH, I don't actually have a ton of experience with it. The firstboot inithooks should allow you to get the basics in place, and the Samba docs should hopefully assist with any remaining questions. If you find any bugs in our appliance, or see gaps that would be good to have filled, or any other feedback then please post back. If you're sure it's a bug, please post straight onto the GitHub tracker.

The fileserver is pre-configered as a stand-alone server, but I'd really like to make it easy to join to an existing domain-controller. Unfortuantely, I didn't get there for v15.0. But it is possible - this page should help head you in the right direction. Again if you have feedback, please share.

Hope that heads you in the right direction... Good luck with it all.

Jeremy Davis's picture

The new appliances have just been published. If you get a chance, please take them for a spin and share your feedback with us. :)

matt wilkie's picture

thanks! is it possible to upgrade from 14.2 LXC in place or do I need to download install from scratch? (We're bandwidth constrained, so conserve wherever possible)

Jeremy Davis's picture

Ideally download the fresh image and do a clean install. That is because we haven't packaged all the tweaks and changes that we've made.

However, as TurnKey is based on Debian (v14.x = Debian 8/Jessie; v15.x = Debian 9/Stretch), it is possible to do a Debian "in place" upgrade. If you do a google for "how to upgrade debian jessie to stretch" you should find plenty of into, although it's essentially just a case of changing the sources.list entries (from jessie to stretch) and running "apt-get update && apt-get dist-upgrade". If you have any data that's important, please make sure that you do a backup first (just in case). If doing a Debian upgrade of a bare metal server, an image (e.g. using something like Clonezilla) is a good option (as Debian upgrades can't really be rolled back).

Good luck and either way, please feel free to post back with any feedback or questions.

matt wilkie's picture

I feel like this is where I've landded:

I've installed a clean TKL LXC on bare metal. The automatic network config didn't work, but I've worked around that. I can connect to lxc server via webmin and ssh and do stuff. Question is, now what? How are sub-containers installed? references 'Turnkey LX Template' which by description does what I'm after, "Download and create a container of any TurnKey appliance", but that script doesn't exist on my new system:

root@lxc ~# lxc-{tab}{tab}
lxc-attach                  lxc-test-clonetest
lxc-autostart               lxc-test-concurrent
lxc-cgroup                  lxc-test-console
lxc-checkconfig             lxc-test-containertests
lxc-clone                   lxc-test-createtest
lxc-config                  lxc-test-destroytest
lxc-console                 lxc-test-device-add-remove
lxc-create                  lxc-test-get_item
lxc-destroy                 lxc-test-getkeys
lxc-device                  lxc-test-list
lxc-execute                 lxc-test-locktests
lxc-freeze                  lxc-test-lxcpath
lxc-info                    lxc-test-may-control
lxc-ls                      lxc-test-reboot
lxc-monitor                 lxc-test-saveconfig
lxc-snapshot                lxc-test-shutdowntest
lxc-start                   lxc-test-snapshot
lxc-start-ephemeral         lxc-test-startone
lxc-stop                    lxc-test-symlink
lxc-test-apparmor           lxc-unfreeze
lxc-test-attach             lxc-unshare
lxc-test-autostart          lxc-usernsexec
lxc-test-cgpath             lxc-wait
root@lxc ~# lxc-{tab}{tab} 


matt wilkie's picture

ahh, in Github the path starts `/overlay/usr` but when installed it's just `/usr`, so the template is in `/usr/share/lxc/templates/lxc-turnkey`.

On running it it tells me path is a required argument. It's not clear if this is a source or destination path. The screen message indicates there's some kind of interaction with `lxc-create`. The help from that tool tells me the required path argument is a destination. Ok, we're getting somewhere.

Looking around the file system I don't see an obvious intended target for containers. `/opt` is empty, as is `/srv`, but maybe they are better placed in they're own disk partitions. Well, there's `lxc-destroy` so I can always move it later (sure hope downloads are cached...).

/usr/share/lxc/templates/lxc-turnkey domain-controller -p /lxc -n domain-controller
FATAL [lxc-turnkey]: inithooks not specified or does not exist

[more reading and experimenting] There's an inithooks example in `/root`. It contains several "password" parameters. It's unclear if these are passwords that already exist or if these are ones which will be created. Throw caution aside and just use the sample unchanged; this is an internal network so using predefined ones is (somewhat) less risky.

root@lxc ~# /usr/share/lxc/templates/lxc-turnkey domain-controller -p /lxc -n domain-controller
debootstrap is /usr/sbin/debootstrap
FATAL [lxc-turnkey]: turnkey version 14.2-jessie-amd64 is not recognized:
root@lxc ~#

Hmm, empty error. Well we've hit a wall and can't go any farther tonight.

matt wilkie's picture

The reference to 14.2-jessie is curious. I'm pretty sure the ISO i downloaded was v15. How do I verify what was written to the boot usb device is v15? And even if I used v14.2 by mistake, it should have worked anyway, just fetched an older version, right?

This what was installed:

root@lxc ~# cat /etc/turnkey_version
root@lxc ~# uname -a
Linux lxc 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux

and the isolinux folder files in the boot-usb:

matt@dell-xps /media/matt/LXC/isolinux $ ls -l
total 608
-rw-r--r-- 1 matt matt   2048 Oct 19 07:25
-rw-r--r-- 1 matt matt 194048 Oct 19 07:25 bootlogo
-rw-r--r-- 1 matt matt  24864 Oct 19 07:25 chain.c32
-rw-r--r-- 1 matt matt  10512 Oct 19 07:25 gfxboot.c32
-rw-r--r-- 1 matt matt  40960 Oct 19 07:25 isolinux.bin
-rw-r--r-- 1 matt matt    109 Oct 19 07:25 isolinux.cfg
-rw-r--r-- 1 matt matt 116552 Oct 19 07:25 ldlinux.c32
-rw-r--r-- 1 matt matt 181944 Oct 19 07:25 libcom32.c32
-rw-r--r-- 1 matt matt    376 Oct 19 07:25 menu.cfg
-rw-r--r-- 1 matt matt  26684 Oct 19 07:25 vesamenu.c32


matt wilkie's picture

2nd run at installing v15 ISO on baremetal worked (xref). I had to edit `/etc/network/interfaces` to get the network working (xref), after that Turnkey template worked too with minimum of fuss.

# /usr/share/lxc/templates/lxc-turnkey domain-controller -n domain-controller \
-p /lxc/domain-controller
INFO [lxc-turnkey]: begin creating container domain-controller...
INFO [lxc-turnkey]: downloading appliance signature debian-9-turnkey-domain-controller_15.0-1_amd64.tar.gz.hash...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
INFO [lxc-turnkey]: successfully completed creating container domain-controller.

So now I'm at the next "now what?" The sub-lxc is installed, how do we get to it and make it do stuff?


matt wilkie's picture

LXC usage mentions lxc-start and lxc-list. Not working here:

0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
INFO [lxc-turnkey]: successfully completed creating container domain-controller.
root@lxc ~#
root@lxc ~# lxc-start -n domain-controller
lxc-start: log.c: log_open: 300 failed to open log file "/var/lib/lxc/domain-controller/domain-controller.log" : No such file or directory
lxc-start: tools/lxc_start.c: main: 317 Executing '/sbin/init' with no configuration file may crash the host
root@lxc ~# lxc-ls f
{empty response}
root@lxc ~#

Well, that's enough for tonight. Maybe sunrise will illuminate. Or moonlight if I get insomnia ;-)

Jeremy Davis's picture

I've been trying to tidy up the remaining v15.0 release lose ends (and I'm nearly done). But I see you've been busy but spinning your wheels a bit. Figured I better at least poke my head in and point you in the right direction...

Apologies if our instructions are not as clear as they should be. Unfortunately, we all suffer from the curse of knowledge. So your insight here would be totally invaluable in assisting us to make the docs more user friendly, especially to the uninitiated!

I think the flaw in your process is that you are using the lxc-turnkey template directly, rather than leveraging the default LXC commands as intended. Perhaps us providing a link to the template file so early in the info creates a bit of a red herring?

The way it's intended to work is via the default lxc commands (which we provider silent wrappers for). That allows existing LXC users to use LXC as they are already accustomed, but allows us to extend the functionality to make it easier for TurnKey users (at least that's the underlaying thought process). FWIW, you can see the wrapper scripts which we provide (on GitHub) here, as you appear to have worked out, they should be on your local server under /usr/local/bin.

All this is noted in the TurnKey LXC docs, however, I note that the page has been moved for v15.0 (it was docs/README.rst before, now it's docs/usage.rst). FWIW you should be using lxc-create (as noted in the docs) to create your initial LXC container. I suspect that your usage of the template file directly is causing the container to not be set up as it should for the other commands.

So to run through it all:

Create your default inithooks conf. Adjust values after the '=' as desired (i.e. set your own passwords, email, domains, etc).

# create default inithooks file
cat > /root/inithooks.conf <<EOF
export ROOT_PASS=secretrootpass
export DB_PASS=secretmysqlpass
export APP_PASS=secretadminwppass

Create the server via lxc-create like this:

lxc-create -n <YOUR_SERVER_NAME> -f /etc/lxc/bridged.conf -t turnkey -- <TURNKEY_OFFICAL_APPLIANCE_NAME>

E.g. to create a TurnKey WordPress appliance which is called wp1 (using the default inithooks.conf created earlier; and bridged networking) run this:

lxc-create -n wp1 -f /etc/lxc/bridged.conf -t turnkey -- wordpress

Then starting it should be as simple as this:

lxc-start -n wp1

FWIW I did test that as part of the testing process prior to release, so it should "just work" as I've posted above (I tested the current ISO prior to release). However, my testing wasn't exhaustive, so if anything doesn't work as you think it should, please don't hesitate to ask more. Perhaps there is a bug we've missed. Also hope my pointers help and you aren't still experiencing gaps...

If you have suggestions on how we can improve the documentation, please edit the files on GitHub. The appliance page is generated from the appliance Readme (I don't think that I'd updated it to the latest version yet, on my todo list...). And the usage docs are here (and I don't think that they are cross posted anywhere else, but perhaps I'm mistaken...?)

Apologies again that I haven't posted sooner. Hope that helps.

matt wilkie's picture

Thanks for the redirection. I started with the template script because that's the one who's description resembled "downloads, installs and configures {thing}", which sounds a lot like  a 'turnkey' process, which is the promised land dream that brought me here ;-) (A refugee after a month of failing to get a Samba 4 domain controller installed and configured on Ubuntu; couldn't resolve dns issues).

In contrast lxc-create and lxc-start are not mentioned at all on the LXC app home page, while something in the template script usage help messages make it sounds like lxc-create is called by template. Looking inside the lxc-create script I don't see anything about where the image it's to use comes from (downloading). i.e. After creation how is it populated? In contrast there's many lines in template about that.



Jeremy Davis's picture

I'm pretty sure that the "-t turnkey" bit of the lxc-create command is what calls the template script.

I haven't actually been closely involved in the development, nor maintenance of the TurnKey LXC appliance. My colleague Alon (who mostly works behind the scenes) created the original appliance and community member John Carver (aka Dude4Linux) has been the primary maintainer/developer since then. Also I don't actually use it myself (I use Proxmox VE on my home server - because it has support for both full VMs as well as containers; and a pretty web UI). So my contact with the TurnKey LXC host (and vanilla LXC itself) is limited to code review and testing (of TurnKey LXC appliance). FWIW Proxmox has it's own container management scripts.

Having said that, the lxc-create man page says:

       -t, --template template
              'template' is the short name of an existing 'lxc-template'
              script that is called by lxc-create, eg. busybox, debian,
              fedora, ubuntu or sshd.  Refer to the examples in
              /usr/local/share/lxc/templates for details of the expected
              script structure.  Alternatively, the full path to an
              executable template script can also be passed as a parameter.
              "none" can be used to force lxc-create to skip rootfs

So that pretty much confirms my suspicions...

I have some suggestions for improving the documentation for new TurnKey LXC users and would love your input:

  1. put a comment right at the top of the template script to explicitly note that it should be called via
    lxc-create -t turnkey <other-lxc-options> -- <turnkey-template-options>
    rather than directly.
  2. move the link to the usage docs much higher on the doc page (and link directly to the usage doc itself, rather than the docs directory).
  3. perhaps even include an example command (using lxc-create) on the main appliance page (or at least a note about how to leverage the template as a dot point under the info about the turnkey template).

The current appliance page somewhat assumes users are already familiar with LXC. That seems to be a clear mistake on our behalf. Do any/all of the above suggestions sound like good ideas to you?

(PS - I hope you don't mind, I just adjusted the title of this thread and added some additional tags.)

matt wilkie's picture

Ok, so I used your commandlines, substituting domain-controller for wordpress. Create reported no errors but start isn't happy.

root@lxc ~# cat inithooks.conf
export ROOT_PASS=secretrootpass
export DB_PASS=secretmysqlpass
export APP_PASS=secretadminwppass

root@lxc ~# lxc-create -n domain-controller -f /etc/lxc/bridged.conf -t turnkey -- domain-controller
INFO [lxc-turnkey]: begin creating container domain-controller...
INFO [lxc-turnkey]: downloading appliance signature debian-9-turnkey-domain-controller_15.0-1_amd64.tar.gz.hash...
INFO [lxc-turnkey]: no change in appliance signature...using cached image...

Ahh, so create also dowloads, and, downloads are cached, great!


root@lxc ~# lxc-start -n domain-controller
Container domain-controller not connected:
root@lxc ~#

Tried starting again:

root@lxc ~# lxc-start -n domain-controller
lxc-start: tools/lxc_start.c: main: 301 Container is already running.
Container domain-controller not connected:
root@lxc ~#

Ok, so something is doing something. `ps ax| grep lxc` shows a single process:

20432 ?        Ss     0:00 [lxc monitor] /var/lib/lxc domain-controller

The DC doc explains there are some additional steps, but at this point I don't know how to get to the DC lxc machine in order to do them. Where does the container go? With the template command target folder was a required parameter.

Well, off to do more exploration and testing.

Jeremy Davis's picture

Perhaps you need to ensure that you have cleaned up from previous attempts using the template file directly? TBH, I'm not 100% sure, but the error(s) that you're getting suggests to me that may be the case?!

I'd start by listing the containers and seeing what's there. Then I'd probably consider removing everything and creating your domain controller from scratch.

matt wilkie's picture

To answer Q from earlier, it looks like the lxc-create containers go to `/var/lib/lxc`.

Lxc-ls only shows 1 container. I tried to remove it with lxc-destroy but am told it's still running. Lxc-stop ran successfully, at least it reported no error. Lxc-destroy again but again a "domain-controller is running" message. Running lxc-stop a 2nd time did the trick, but then once again lxc-destroy says container is still operating. `lxc-ls --full` confirms container is running.

root@lxc ~# lxc-ls -f
domain-controller RUNNING 0         -      -    -
root@lxc ~# lxc-stop -n domain-controller
root@lxc ~# lxc-ls -f
domain-controller STOPPED 0         -      -    -
root@lxc ~# lxc-destroy -n domain-controller
Container domain-controller not connected:
domain-controller is running
root@lxc ~# lxc-ls -f
domain-controller RUNNING 0         -      -    -
root@lxc ~#
matt wilkie's picture

Thinking a background script is automatically spawning the controller I periodically checked the running status with `lxc-ls -f` and `lxc-info` while I did other things. The goal being to determine the schedule and time the destroy command accordingly. Didn't work, the state is always stopped until I run lxc-destroy. I even tried chaining together in a single command with `&&`.

I then tried to login to the container and shut it down from inside, using `lxc-console`, but got stuck in a loop. It wouldn't recognize my password. I tried the ones from inithook, the master lxc password, and some others just for fun. All of them were unrecognized. There was no way to break out of the login cycle, to say "I give up! let me out!". I had to open another ssh session. Sometimes when I hit [enter] at the end of my password an 's' would show on screen, so my guess is the right keys weren't being sent through.

I tracked down the lxc-destroy script and stepped through, manually running the lines I can understand. Ahhh! This is what's booting up the container again:

root@lxc ~# lxc-info -n domain-controller
Name:           domain-controller
State:          STOPPED

root@lxc ~# which lxc-destroy

###...inspect script...

root@lxc ~# /usr/local/bin/lxc-dnsmasq-update --delete domain-controller
Container domain-controller not connected:

root@lxc ~# lxc-info -n domain-controller
Name:           domain-controller
State:          RUNNING
PID:            10711
CPU use:        3.37 seconds
BlkIO use:      688.00 KiB
Memory use:     61.28 MiB
KMem use:       10.48 MiB

And now we are successful:

root@lxc ~# lxc-stop -n domain-controller
root@lxc ~# lxc-ls -f
domain-controller STOPPED 0         -      -    -

root@lxc ~# /usr/bin/lxc-destroy -n domain-controller
Destroyed container domain-controller

root@lxc ~# ls /var/lib/lxc/
### ...sub dirs are gone...

root@lxc ~# nginx-proxy -r -d all -n "domain-controller"
root@lxc ~# ssh-keygen -R "domain-controller"
do_known_hosts: hostkeys_foreach failed: No such file or directory
root@lxc ~#

matt wilkie's picture

Success! Well, at least as far the stage 1 rocket. The domain-controller container is installed, runs, and reports an IP. Now to figure out Samba AD config.

root@lxc ~# lxc-create -n dc -f /etc/lxc/bridge.conf -t turnkey -- domain-controller
INFO [lxc-turnkey]: begin creating container dc...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
INFO [lxc-turnkey]: successfully completed creating container dc.

root@lxc ~# lxc-start -n dc

root@lxc ~# lxc-ls -f
dc   RUNNING 0         - -


Ok, to my mind all that's needed to make this TURNKEY is a number of simple scripts following the form of LXC-install-{appname}. The scripts are included in turnkey-lxc-appliance image, and can be updated periodically with something similar to `apt-get update`.

It asks 2 questions:

  • password for this app?

The same password can be used for all 3 invocations - host os, sql db, and app. People who want to use it in the wild with more security levels can still edit inithook.conf.

  • hostname for this app?

We don't need the app name (lxc-create --name=..), we already have that, it's in the script name.

Bridged vs NAT? well that could be asked too I 'spose without complicating things. It's a simple boolean. Other options? Well they're all still available in the existing commands.

A newbie's 2$

Jeremy Davis's picture

Great work. Really glad to hear that you got it running! Re the previous suggestions I had, I've opened an issue on our issue tracker so it doesn't get forgotten. I'll aim to have it updated at least by our next release (although ideally sooner).

So let me see if I get you straight, you're suggesting an (interactive) script which the user could run which could:

  • allow setting a common password (and thus avoid the requirement of generating an inithooks file)
  • set the hostname. TBH, not sure if we'd need that?! IIRC the name you give the appliance automatically becomes the hostname doesn't it?!
  • set networking - bridged or NAT

WRT naming this script, we have a precedent of prefixing TurnKey specific scripts with turnkey- (e.g. turnkey-version). I'd be inclined to stick with that precedent. Although we could provide an alternate name starting with lxc- (probably including turnkey or tkl in the name too to make it clear where it comes from).

If we were to develop this script, my inclination would be to allow it to accept arguments (e.g. --password) (so it could run non-interactively). But any arguments not supplied would be asked. Perhaps to add value, it would also start the freshly created/configured container?

TBH, I'm not sure if/when we'll get to that, but in essence I think it's quite a cool idea. If you want to hone your bash skills, then perhaps it's something you might want to have a crack at?! :)

Jeremy Davis's picture

It may not be immediately obvious, but there are additional (optional) inithooks that apply to some of our servers. It's a little out of date (and needs update for v15), but the inithooks readme documents most of them.

You can also re-run them (all) interactively by running turnkey-init. Or you can re-run the applaince specific ones by launching them directly. E.g. for the Domain Controller appliance; run /usr/lib/inithooks/bin/

Again, it needs updating for v15, but there is some documentation that should still be (mostly) relevant in the docs regarding the domain controller here. The info is (sort of/somewhat) replicated on the website in the appliance specific docs.

As you are no doubt aware by now, documentation is an area of TurnKey where we are sadly lacking and need some significant improvement...

matt wilkie's picture

I neglected to say Thank you Jeremy for your frequent checking in and nudges in the right direction. It really helped. I likely would have given up if I didn't see you paying attention, and being receptive to feedback.

Jeremy Davis's picture

I really enjoy helping people out (I'm actually a social worker by profession). And I want TurnKey to be the best that it can be. I want it to be the best, most user friendly server distro around. As Alon and Liraz (the TurnKey founders) are wont to say; "easy things should be simple and hard things should be possible"! We've still got a long way to go, but I'd like to think that we'e making progress.

FWIW I learned most of what I know about Linux while helping people here on the TurnKey forums! I was a complete Linux newb when I first came across TurnKey. But it really piqued my interest, so I spent heaps of time trying to help people (talk about the blind leading the blind...) and I learned so much along the way. Then one day, Liraz offered me a job with TurnKey and they'll never get rid of me now! :p

matt wilkie's picture

Work in progress. I'll continue to update this post for awhile.

Goal: A home Active Directory based environment from one physical machine.

With Samba 4, this means one server as Domain Controller and a second as File Server, with both of these hosted in an LXC container. Everything is behind a router and not directly exposed to internet.

[1] Download and create bootable USB or CD from Turnkey Linux Containers image.

Install it. Possibly need to fix network settings.

It lives at: http://lxc.home.lan/

[2] Install LXC Domain Controller:

Create default inithooks conf. Adjust values after the '=' as desired (i.e. set your own passwords, email, domains, etc).

# create default inithooks file
cat > /root/inithooks.conf <<EOF
export ROOT_PASS=secretrootpass
export DB_PASS=secretmysqlpass
export APP_PASS=secretadminwppass

Download and install Domain-Controller:

lxc-create \
  -n dc \
  -f /etc/lxc/bridged.conf \
  -t turnkey -- domain-controller

-n dc: what to name the machine, e.g. \\dc from a Windows workstation.

-f .../bridged.conf: use bridged network config, the DC will show up as a unique machine on the network, distinct from the LXC controller.

-t turnkey: tell LXC scripts to use the turnkey template

-- domain-controller: the name of the Turnkey app to download and install. Important: there is intentional whitespace between `--` and `domain-controller`

Start the domain controller:

lxc-start -n dc

It lives at: http://dc.home.lan/ and \\dc

[3] Install LXC Fileserver:

largely same as #2.

lxc-create \
  -n files \
  -f /etc/lxc/bridged.conf \
  -t turnkey -- fileserver

It lives at: http://files.home.lan/ and \\files

[4] Join Fileserver to domain.


(I don't have this part working. Fileserver is joined to domain but user syncing etc. is not happening).

[5] Join windows workstation(s) to domain.

Install RSAT tools for easier domain administration, including user and group management. Some of the tools error out, but the important ones work.

[6] Live long and prosper.

Jeremy Davis's picture

Thanks for this Matt. I'm sure that this will be useful for others.

As noted elsewhere, I've removed your duplicate posts and mildly edited the one I left.

Re the user mappings on your Fileserver, FWIW our Fileserver uses a Samab3 style config which maps Samba users to Linux users. Historically, the automation of the synchronisation of that was handled by a samba module that plugged into the Linux user management system. However it was since discovered that there was a security issue with that module and Samba are no longer maintaining it, so it is gone...

My understanding is that Samba4 style config (as default on the domain controller appliance) uses a single Linux user account to contain all Samba users. However for that to work. it requires filesystem ACLs (they allow additional info beyond the basic Linux file permissions system).

So I may be incorrect, but AFAIK, on your fileserver, you have 2 options.

1. Manually create all your users on the fileserver (both Samba and Linux). Obviously that will only work in a home type environment where you will rarely need to add additional users. In an SMB environment it's probably sub-optimal. Also note, that if any of the Linux users are used (e.g. SFTP), that passwords will not be auto synced. So if a user changes their Windows/Samba password, that will not automatically update the password of the Linux user. This may not be an issue, but I wanted to raise it. TBH, I forget what implications that may have for the fileserver files webUI.

The other option would be to enable ACLs. TBH, I'm not 100% sure how to do that on an LXC guest, but I do know that it will depend on support from the host (I.e. the LXC host appliance will need to have them enabled). You may also need to manually add something to the LXC guest config file to pass them through to the guest. Hopefully google will assist there...

Please share if you find anything interesting and/or useful. Alerting other users is really helpful and may also give us ideas of stuff which might be useful to pre-configure in a future release.

John Carver's picture

Welcome to the world of TurnKey GNU/Linux.  Sorry to hear that you had some problems getting started.  Despite the name TurnKey, there is still a bit of learning curve for new users, especially for more complicated appliances like LXC.  I remember being exactly where you are when I started working with the LXC appliance several years ago.  Reading the thread above, I would say that you're getting up to speed faster than I did. :)

  • Documentation is always the last thing to be written
  • By the time documentation is written, the developer is so familiar with the operation that it's easy to miss the parts that are not obvious to a beginner

Thanks for being an involuntary guinea pig re: testing of the v15.0 LXC appliance.  Your experience should help us improve the documentation for v15.1.

I've issued a new git pull request that addresses the network issues you mentioned.
Update confconsole for v15.1 #25  They are now waiting for Jeremy's approval and releasing an updated Debian package for confconsole.

In the meantime, if you would like to test the changes in your environment, you can download new copies of:


To run the test, first backup the original files above and your current /etc/network/interfaces file.  Next replace the files from the links above and restore the default /etc/network/interfaces which should look something like this

# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
    bridge_ports eth0
    bridge_fd 0
    bridge_maxwait 0

auto natbr0
iface natbr0 inet static
    bridge_ports none
    bridge_fd 0
    bridge_maxwait 0

Then you should be able to use confconsole to switch between DHCP and static modes as well as change the hostname.

Information is free, knowledge is acquired, but wisdom is earned.

Add new comment