I am not a Incus/Podman/Apparmor expert, but I also tried to run rootless Podman inside Incus containers on an Ubuntu 24.04 host recently, and also ran into this error message, so here’s my 2 cents.
The error is caused by the new default AppArmor settings in Ubuntu:
Restricted unprivileged user namespaces are coming to Ubuntu 23.10 | Ubuntu
As such, unprivileged processes will only be able to create user namespaces if they are confined and have the “userns,” rule in their AppArmor profile (or if they have CAP_SYS_ADMIN).
and some more background:
[spec] Unprivileged user namespace restrictions via AppArmor in Ubuntu 23.10 - Project Discussion / Security - Ubuntu Community Hub
The upstream AppArmor project recently introduced a mechanism to allow the use of unprivileged user namespaces to only those applications that both require the access and are appropriately confined by AppArmor (and to deny access to all other applications).
So it’s about kernel.apparmor_restrict_unprivileged_userns which is set to 1, so the restriction is enabled.
And as Incus creates a AppArmor namespace (something like ‘:incus-containername_<var-lib-incus>:’), there must be a AppArmor profile ‘unprivileged_userns’ in the AppArmor namespace, in order to let Podman create unprivileged user namespaces.
(like it says in the error message in you dmesg output:
info=“Userns create restricted - failed to find unprivileged_userns profile”
error=-13
namespace=“root//incus-mycontainer_<var-lib-incus>”
So there are options:
- disable the restriction:
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 - Setting
raw.lxc: "lxc.apparmor.profile=unconfined"in the container config - Manually create the unprivileged_userns profile, by using AppArmor on the host. Something like
sudo apparmor_parser -n 'incus-mycontainer_<var-lib-incus>' -r /etc/apparmor.d/unprivileged_userns - Use your own AppArmor profile, with
raw.apparmor = profile - Running Apparmor in the Incus container and let it create a default unprivileged_userns profile in its root (which is actually the “root//incus-mycontainer_<var-lib-incus>” namespace)
- Let Incus also create the unprivileged_userns profile when it detects that kernel.apparmor_restrict_unprivileged_userns is enabled.
In my opinion, based on what I’ve read, options 1 and 2 are insecure.
Option 3 and 4 are not really feasible, as it has to be done for every Incus container namespace (3 even after every start/restart)
(but nice for testing/understanding)
Option 5 is what I now use and I think is fine. I’ve disabled all other AppArmor profiles in the Incus container, to not introduce unwanted restrictions or unneeded permissions that might enable an attacker to escalate from regular user in the Incus container to root in the Incus container.
You have to have a container that supports installing AppArmor, but bonus is that you can use AppArmor in the Incus container to further restrict processes in the container.
Options 6 or any other solution that the Incus developers will come up with is of course the best in the long run.
There is also a setting kernel.apparmor_restrict_unprivileged_unconfined which might give problems, but that’s a whole other can of worms 
Running ps axZf or sudo aa-status on the host also helps to see what’s going on.