You are not allowed to run the mount syscall inside of an unprivileged container, as a malformed/malicious source disk could be used to crash the host kernel.
You could mount this on the host and then pass the resulting mount into the container using the disk device type.
Or if you’re happy to take the risk then look at using the syscall interception security.syscalls.intercept.mount.* feature:
I think you may have missed the point. I am trying to point virtual disks that are entirely inside the container or even ISO’s entirely inside the container, so they are not based on the host. I frequently do mount folder paths from outside the container from the host and that is easy.
Ok I see. Either way my point about mount syscall not being allowed stands because a malformed disk image could crash the host kernel. This limitation doesn’t apply to lxd vms though.
I did notice that. I have a couple LXD VMs and all is fine. I just wanted to find out if it was possible to “loop” mount a device in a regular LXD container. It seems many folks have gotten close. I think my example is close. I just thought you might know what I am missing. The concept is easy. The syntax is abstract.
I read about the feature and added it to my test container created above and it gives me a permission error. It looks what you said should work, but apparently in what I provided you above, something else is wrong. Again:
Thanks Thomas. It worked as you said. My missing part of the puzzle was in not understanding the security.syscalls.intercept.mount.allowed=ext4 was needed and also the loop device is squirrely. For me, this was mainly an exercise, since I generally mount data from the host which is preferred. I was able to use your instruction to mount both a virtual disk image file and also an ISO. I was unable to have more than one loop device mounted at once even if I added loop devices to the container. I am not sure why. The issue that got me interested in this was I ran into more than one self-hosted application that failed to run in a LXD container because they were trying to access a loop device.
I tried this to no avail. Note above: I was unable to have more than one loop device mounted at once even if I added loop devices to the container. I am not sure why.