Snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine*

Fixes it. No restart required.

This worked for me

service snapd.apparmor start 

(It needs the root.)

sudo systemctl start apparmor 
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*

systemctl enable --now apparmor.service    
systemctl enable --now snapd.apparmor.service

from here

This is what worked for me on Kali Linux:

sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine*
systemctl enable --now snapd.apparmor.service

In my case it was caused by a bad AppArmor profile being present and loaded in complain (or enforce?) mode in

/etc/apparmor.d/usr.bin.snap

This apparently lead to snap not being able to determine the number of the snap and therefor caused a bad profile to be added to AppArmor.

"aa-status" outputed lines such as:

/usr/bin/snap//null-/usr/lib/snapd/snap-confine

for being in enforce mode

I moved that file (/etc/apparmor.d/usr.bin.snap) to my home directory, ran "sudo aa-remove-unknown" and "sudo systemctl restart apparmor" after which everything was back to normal.

However I don't know the origins of /etc/apparmor.d/usr.bin.snap so keep in mind that there might be something wrong with the system.

I had the same problem when using snap to run scrcpy. I tried this suggestion first and it worked:

sudo snap refresh

(This suggestion found at https://github.com/canonical/microk8s/issues/249)

This command also worked in my case :-

$ sudo service snapd.apparmor start
$ whatsdesk

Thank you.

What is really works is pavlikoo's answer

But in some cases, it also would be better to execute first:

sudo systemctl enable snapd

And don't forget to add sudo to pavlikoo's commands if you don't have special permissions.