Disk device inside unprivileged container with shiftfs

Since the last LXD update to version 4.24 I’m experiencing difficulties with adding a host folder as disk device to my unprivileged containers:

lxc config device add c1 common_share disk source=/opt/common_share path=/opt/common_share shift=true

Error: Failed to start device "common_share": Required idmapping abilities not available

Most likely this has to do with the “restricted.containers.interception project option” paragraph in the release notes but as a relative new LXD user this doesn’t point me in the direction of a solution.
Making the container privileged solves the problem but that’s not what I want. Also leaving out the shift=true option and setting rwx permissions for all users on the share folder does work but is not very elegant.
Ideally I’d like to have the old situation back. Is there any way of doing that? I’m aware about the security implications but for me it seems to be the most practical solution.

That’s unrelated to this change, syscall interception doesn’t have anything to do with filesystem shifting.

What filesystem is backing /opt/common_share?
What kernel are your running on the system?
What’s the output of snap get -d lxd?

snap set lxd shiftfs.enable=true followed by systemctl reload snap.lxd.daemon should get you back in business.

It’s a bugfix in 4.24 which technically caused that regression, we’ll be fixing it.

This should fix it:

Works great, thanks!

For reference, that PR is now available here: LXD: Allow disabling shiftfs independently of idmapped mount support by tomponline · Pull Request #10095 · canonical/lxd · GitHub.

Seeing this on a machine where I newly installed LXD 5.0, and the device in question is an NFS mount.

This workaround seemed to help, thanks a lot @stgraber. :pray: