Snap stopped working on wsl?

I have WSL2 preview version installed (so I can use the new systemd support). I'm running the latest version of WSL Ubuntu (not preview) and when I run snap install <insert_program_here> or any program installed with snap (like lxd) it returns

Interacting with snapd is not yet supported on Windows Subsystem for Linux.
This command has been left available for documentation purposes only.

So the lxd command has the same output. I also enabled systemd by adding

[boot]
systemd=true

to /etc/wsl.conf

wsl -v returns:

WSL version: 0.70.4.0
Kernel version: 5.15.68.1
WSLg version: 1.0.45
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1098

and snap --version returns:

snap                         2.57.4+22.04
snapd                        unavailable
series                       16
Windows Subsystem for Linux  -
kernel                       5.15.68.1-microsoft-standard-WSL2 (amd64)

@EduGomezEscandell beat me to it, but also updating this answer to note that this is fixed in the latest Snapd:

sudo apt update && sudo apt upgrade -y

(or target Snapd specifically as Edu mentions). After updating, Snap/Snapd should work properly under the latest WSL/Systemd releases.

Remember to revert any workarounds (e.g. below). A wsl --shutdown is also need to return your binfmt_misc to normal.

Historical information:

As @olem's answer mentions, this does seem to be due to an intentional Snap change that was designed to "fail gracefully" on WSL. For me, this only appears to be an issue on Ubuntu 22.04 with Snap/Snapd version 2.57.

The version that comes with Ubuntu 22.04 on first install in WSL is currently 2.55, so snap works at first, out-of-the-box, then fails after the first sudo apt update && sudo apt upgrade.

The problem does not appear to occur on Ubuntu 20.04, even when fully updated, as the latest release there is 2.55.5.

According to the Launchpad bug, this surfaced when a separate bug was recently fixed.

Side-note: Also being tracked in this WSL issue, although we know it's not actually a problem in WSL itself.

Steps you can take if you are experiencing this issue:

• Implement a temporary workaround

  A good workaround is found in this Github comment:

  echo ":windowsexe:M::\x4d\x5a::/init:PF" | sudo tee -a /etc/binfmt.d/windowsexe.conf
  

  Then exit Ubuntu, wsl --terminate <distroname> (in PowerShell or CMD), and restart.

  This file is processed at startup and "reregisters" the WSL Interop support (that allows you to run Windows binaries) with a different name, thus thwarting the method that Snap uses to detect that it is running under WSL.

• "Upvote" the issue on Launchpad

  Create an account on the Ubuntu Launchpad and click the Affects me too link at the top of the issue page.

• Monitor the status

  You can monitor the status at the main Launchpad bug.

  While the fix is merged, it still needs to get pushed into the 22.04 update channel. From watching this WSL bug on Launchpad, the fix will first need to go into jammy-proposed, where at least one user will need to test and confirm the fix before it will be released to -updates.

  I'm honestly not sure how we get this to the next step, though. I'll attempt to research.

• Important: Revert the temporary workaround once the updated Snapd with the fix is updated on your system

  Make sure that, when the fix for this bug is pushed into the Ubuntu update channel, that you remove /etc/binfmt.d/windowsexe.conf so that you return to allowing WSL to set this up for you. The method has changed slightly over time, and you'll want to be sure that, in the long-term, you are using the settings that WSL expects.

This is an issue with snapd 2.57.4. A fix was released today. Simply do

sudo apt-get -y update
sudo apt-get -y upgrade snapd

This'll upgrade you to snapd 2.57.5 and you'll be set. As mentioned in another comment, you can see the discussion in this Github issue