Windows Subsystem for Linux


Is Snappy supported on Windows Subsystem for Linux aka Bash on Ubuntu on Windows? I have tried it on Windows 10 with the Creators Update which runs Ubuntu 16.04 and I am getting the following errors.

$ snap version
2017/04/06 19:49:29.797600 main.go:220: WARNING: cannot create syslog logger
snap 2.22.6
snapd unavailable
series -

$ sudo snap install hello-world
[sudo] password for donald:
2017/04/06 19:51:35.679700 main.go:220: WARNING: cannot create syslog logger
error: cannot communicate with server: Post http://localhost/v2/snaps/hello-world: dial unix /run/snapd-snap.socket: connect: no such file or directory

Snap install permissions glitch

The snap command seems to be running appropriately, the first WARNING is perhaps related to the fact that WSL does not have a syslog, the second problem is that snapd seems to not be running, see what’s going on by running

systemctl status snapd


Thanks for your quick response.
I have installed the latest version of snapd by running apt-get update and apt-get upgrade.
Here is the output from a couple of commands including the one you suggested.

$ sudo apt-get install snapd
[sudo] password for donald:
Reading package lists… Done
Building dependency tree
Reading state information… Done
snapd is already the newest version (2.22.6).
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.
$ systemctl status snapd
Failed to connect to bus: No such file or directory


Does WSL support services at all? If not, that needs to be enabled first.


Good point! I’ll see what I can find out. It might be some time before I can get back to this discussion.


Just to add that I would love to see snapd working on as many OS platforms and Linux distros as possible so if anyone is willing to dig in and figure out what it takes to get snaps working where currently they don’t, that work is super valuable. Let us know how we can help.


Couple of months back I tried installed snapd as well as mongodb, and docker. All seemed to hang up with the service. I’m not sure what about it wasn’t working, I didn’t dig that far.


On my stand-alone Ubuntu machine (on which Snappy does work) there is no sign of a snapd service when I try $service --status-all but there are the following entries in the /run directory: snapd, snapd-snap.socket and snapd.socket. These entries do not exist in my WSL installation.
I have tried removing and reinstalling snapd but this has made no difference.



I discussed this with @tvoss and the WSL folks some time back, it’s challenging to support snaps natively because:

  • this would need systemd or an alternate backend for services in snapd
  • this would require a bunch of new features like squashfs mounting, mount namespaces and more

Perhaps the simplest to start with would be classic snaps without services.


  • Loïc

Using snap on Windows Server 2012 R2

There are several technical shortcomings, that I can think of, that make snapd not really work:

  • there is no systemd on windows, we use systemd extensively in snapd
  • last time I checked squashfs files could not be mounted
  • there is no confinement support but ubuntu build requires it

I can recall some people made an experiment where a fake systemd would be installed (just a bunch of scripts) that would unpack squashfs files and would fake some service startup but this was barely a demo, at best.


Yes, that is what we did (or Matteo) did for OpenWRT. See the scripts here for some more details. This should get you around the missing systemd but leaves the other two points (confinement, squashfs).


Hi All,
Thanks for all your replies. Perhaps not the answer I was hoping for but, at least, you have cleared up the situation.


Hi all,
@morphis, thanks! Your scripts are what I would try on Slackware. Are they work reliable for you on OpenWRT?


You’re going to have a bad time with this, as the functionality of Snaps have evolved considerably since those scripts were made and snapd expects more things from systemd.

You’d be better off setting up a deputy systemd under your current init. The reason it couldn’t be done for OpenWrt was because of the size constraint and the old kernels. Slackware should have no such restrictions.

Last I checked, there was also some SlackBuilds for setting up systemd on Slackware, so that’s an option, too.


Thanks @Conan_Kudo.
Unfortunately, Slackers hate systemd, so it’s seems no ready way to incorporate systemd there.
All I found is systemd packages in Dlackware - Dropline Gnome Slackware, which seems just swaps Slacware’s system init to systemd, for Gnome3 usage. But it is not what I want.
So, my current intention is to run systemd in Docker container in Slackware. Maybe I would have better luck with it.
But to be honest, Snaps dependency on systemd seems awkward for me…
Thanks anyway


Hi, I’m having the same problem. I’m running the very latest Windows 10 Preview and as far as I can see systemd is supported. However, I have the same error messages due to snapd not being started. I’ve started started snapd manually, which seems to work. However, now I have the mentioned issue with squashfs. Looking into that.

UPDATE: this is the error I get

unsquashfs -i -d /tmp/read-file468023474/unpack
/tmp/snapd-sideload-pkg-827422431 meta/snap.yaml" failed: exit status 1 ("Read on filesystem
failed because EOF


Systemd is not supported in WSL. Snapd is not installed since that (and many other things) are not available on Windows.

Building the snap on Windows

Does anyone have the current status of snap support on WSL2? AIUI, there are some missing patches for AppArmor in the kernel there and maybe missing squashfs support? Anything else missing?


systemd is not being used as the init process (PID 1). You can try to mess about to try to get it to operate as not-PID-1 but it is not easy.


I know this was the case for WSL1, is it still the case for WSL2?