Hey folks, I have a container that I can’t start or delete. I think it may be caused by the container having a nested cgroup type thing. If I try to delete the container I get:
rm: cannot remove '/var/snap/lxd/common/lxd/storage-pools/default/containers/juju-7d7a7e-0-lxd-4/rootfs/var/lib/docker/btrfs/subvolumes/4770ba21798b7d036985cafa9c439860118190ebbe97b05ee
9a814e7e451ac28': Operation not permittedYou are using
$ lxc stop cn_name
$ lxc delete cn_name
You could also try
$ lxc delete cn_name --force
You would get that error if the specific subvolume ( 4770ba21798b7d036985cafa9c439860118190ebbe97b05ee) was not unmounted yet, when LXD tried to remove it. Most likely a timing issue. By trying again, it might be able to get deleted.
I had this issue even when I tried with lxc delete --force mycontainer on ZFS, when ZFS for some reason was sluggish to respond. On the third attempt it would work.
In your case I can see references to Juju and docker. Most likely it needs a bit more time for the scaffolding to be removed, before deleting.
What’s your storage pool type?
This kind of things happen when you’re using the dir backend on top of a btrfs system.
In that mode, LXD doesn’t know that you’re using btrfs but the containers may still use some of its features.
This leads to such undeletable directories as they’d require a btrfs subvol delete to be run before they can go away.
I believe the Storage is BTRFS in the container and DIR on the host. Juju provisioned this so 
it’s probably my fault for not paying attention to the storage driver docker used inside the lxd container.
Anyway, thanks for the replies folks. Several rounds of deleting subvols later the container is gone!