Future-proof your skills with Linux, Python, vim & git as I share with you the most timeless and love-worthy tools in tech through my two great projects that work great together.

LXD Container on Windows WSL2 Using NAS SMB/CIFS Share

After struggling to set up a LXD container, I found the solution to my problem - mapping my NAS, .ssh folder, .gitconfig, and .vimrc files, and then running two commands from within the container. I also had to mount a Windows network share using the command 'sudo mount -t drvfs '\\EchidNAS\data' /mnt/data'. Now my LXD container is running as expected.

Successfully Setting Up LXD Container on Windows WSL2 with NAS SMB/CIFS Share

By Michael Levin

Monday, July 25, 2022

The forcible push forward because now I have lxd/lxc containers running as easily as I had imagined. LXD really is like it’s built into Linux now. And I’m running Linux under Windows, so LXD feels like it’s built into Windows!

It’s been suggested to me to run Docker for Windows (or even LXD for Windows, which I think exists), either of which would give me Linux containers under Windows. But that’s not the goal. The goal is Linux containers under Linux in preparation for a Windows-free future. Windows is ALWAYS optional. Any time you’re introducing a new development tool from the Windows-side, beware! You’re being boxed-in by Microsoft.

Issues for today to solve to forge forward are:

I need a place for big Sqlite files! I plan on doing a lot of work that will be “database back-ended” (if even using the Python dict key/value API). Throw the results of a lot of requests into a “raw data bucket”. And so the container’s “virtual” hard drive does not seem an appropriate place. I’m going to map in probably a location on my home network, from my NAS (network application server). I can share drive locations from there and it’s in the context of my home local area network (LAN) behind router.

I already have my ~/github folder mapped (which i

Mount host’s “home” location as container’s “home” location:

lxc config device add container-name home disk source=/home/${USER} path=/home/ubuntu

I need to choose between mapping WSL host-Linux’s home to the LXD container or the github folder, which is itself a symlink on the Linux host. Catch-22. That’s an interesting vid. Do a part 2.

After removing all mounts from container, try this:

lxc config device add GlookingLass home disk source=/home/${USER} path=/home/ubuntu
lxc config device add GlookingLass github disk source=/mnt/c/Users/mikle/github path=/home/ubuntu/github

Ugh, no luck!

Okay it seems like I have to choose the best compromise. And it was very close to my original plan!

So first I have to re-establish this from the WSL Linux Host for LXD:

ln -s /mnt/c/Users/mikle/github /home/healus/github

Okay, so now I have my github folder from the Windows-side symlinked into the Linux-side.

lxc config device add GlookingLass github disk source=/mnt/c/Users/mikle/github/ path=/home/ubuntu/github/
lxc config device add GlookingLass dotssh disk source=/mnt/c/Users/mikle/.ssh/ path=/home/ubuntu/.ssh/

What are the other folders?

Yeah, my initial gut is right. Of all these, only .ssh needs to be mapped in, in addition to github.

But there are a few files that could use to be moved over:

Hmmm, well .vimrc is already in the vim repo. And my bash script for editing my journals ensures it’s always up-to-date there, so I should really just throw my .gitconfig into my ~/github/vim folder and grab it out of there on a 1-time basis from new containers.

Okay, and now finally to have a home sweet home, we just execute these 2 commands from within the container:

cp ~/github/vim/.vimrc ~/
cp ~/github/vim/.gitconfig ~/

Ugh! When trying to git clone I get this error:

[py310] ubuntu@GlookingLass:~/github $ git clone git@github.com:miklevin/oauthlogin
Cloning into 'oauthlogin'...
error: chmod on /home/ubuntu/github/oauthlogin/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'

All the advice on the net involves doing this:

Save the file and shutdown WSL launching wsl –shutdown from a PowerShell Relaunch Ubuntu WSL

I did this to the Linux host machine, and it miraculously did it.

[py310] ubuntu@GlookingLass:~/github $ ps -aux
root         1  0.0  0.1 224520  8188 ?        Ss   16:59   0:00 /sbin/init
root       216  0.0  0.2  94584 13048 ?        Ss   16:59   0:00 /lib/systemd/systemd-journald
root       220  0.0  0.0  42108  3564 ?        Ss   16:59   0:00 /lib/systemd/systemd-udevd
systemd+   234  0.0  0.0  79924  5208 ?        Ss   16:59   0:00 /lib/systemd/systemd-networkd
systemd+   259  0.0  0.0  70496  4900 ?        Ss   16:59   0:00 /lib/systemd/systemd-resolved
root       260  0.0  0.2 170748 17512 ?        Ssl  16:59   0:00 /usr/bin/python3 /usr/bin/netwomessage+   261  0.0  0.0  49932  4420 ?        Ss   16:59   0:00 /usr/bin/dbus-daemon --system -syslog     262  0.0  0.0 193412  4048 ?        Ssl  16:59   0:00 /usr/sbin/rsyslogd -n
root       263  0.0  0.0  70468  5900 ?        Ss   16:59   0:00 /lib/systemd/systemd-logind
root       264  0.0  0.0  31296  3124 ?        Ss   16:59   0:00 /usr/sbin/cron -f
root       267  0.0  0.0  15964  2436 ?        Ss+  16:59   0:00 /sbin/agetty -o -p -- \u --noclroot       268  0.0  0.3 187228 20372 ?        Ssl  16:59   0:00 /usr/bin/python3 /usr/share/unaroot       406  0.0  0.0  64768  3780 ?        Ss   17:04   0:00 su --login ubuntu
ubuntu     407  0.0  0.1  76404  7232 ?        Ss   17:04   0:00 /lib/systemd/systemd --user
ubuntu     408  0.0  0.0 258496  2852 ?        S    17:04   0:00 (sd-pam)
ubuntu     418  0.0  0.0  21612  3980 ?        S    17:04   0:00 -su
ubuntu     429  0.0  0.0  39672  3580 ?        R+   17:04   0:00 ps -aux

There’s so little running there, I should be able to know each one pretty well. This is the “before”, before I add something running automatically under systemd.

Alright, this is right on the verge of the damn busting wide open.

It took awhile for me to get here.

Take a few deep breaths. Make sure you can build something up in good baby-steps. Document it here. Get it running here. Then use that as your starting point for your next step at work.

Get your dashboards running under Huey on your home network first.

Start development local on your laptop, on an LXD container under WSL. This native Linux container development under Windows 10 without any proprietary Windows software except for the WSL-stuff now built-in. This is the beginning of the “into the future” transition plan off of Windows.

Document the precise next steps.

Okay, we’re going to be creating a Python scheduling daemon.

Or should that be a Python Scheduling Demon for clickbait?

It all starts here:


And the file that would be named pulse.service that goes in there follows a specific convention laid out here:

Description=Run Python script to handle scheduling

ExecStart=/usr/bin/screen -dmS heartbeat /home/ubuntu/py310/bin/python /home/ubuntu/github/heartbeat/pulse.py


Such a file needs to be put or created in place with admin privileges. Merely by virtue of being there, there is now a basis set of systemctl controls for it, or usually also “system” controls if you prefer.

Hmmm. While I feel ready to jump right into systemd stuff finally, there’s just one more bit of housekeeping I need to tend to first. And that’s the use of Windows network shares like SMB/CIFS from a container. Doesn’t look like it’s built in.

I went on a wild goose chase with smbclient. It turns out it’s not necessary! Uninstall it because it also put in a lot of python 3.7 stuff. Remember to do:

sudo apt autoremove

…to clean up after anything that’s been left behind. Okay. So this looks like it works on the WSL Linux host.

The amazingly simple answer was:

mkdir /mnt/data
sudo mount -t drvfs '\\EchidNAS\data' /mnt/data

However, if this is tried on an LXD container, I get:

unknown filesystem type 'drvfs'

Interesting! This drvfs looks like a WSL thing. Since it does not work on a container, one more command is required from the Linux WSL host in order to make this location available to the container. But we should settle in on a ~/data convention. So next we do this on the WSL Linux host:

sudo ln -s /mnt/data /home/healus/data

We will still want to connect it from /mnt/data in the container, so we do this:

lxc config device add GlookingLass data disk source=/mnt/data path=/home/ubuntu/data

And I start the container and it’s there!