Closed kcgthb closed 5 years ago
Yeah, unfortunately you can only start images directly on Linux >= 4.18. This is because you need fuse support in user namespaces (https://github.com/torvalds/linux/commit/4ad769f3c346ec3d458e255548dec26ca5284cf6).
AFAIK RHEL 7.X doesn't have this patch, RHEL 8 might though.
In the meantime, you will have to unpack the image, and create a statefull container out of it:
enroot create alpine.sqsh && enroot start alpine
Note that you could also mount the image outside of enroot, either
runtime::_mount_rootfs()
with fuseThen you could use ENROOT_DATA_PATH=... enroot start ...
to start it.
The difference is that you will have to cleanup/unmount after you're done with the rootfs since there are no namespaces in this case, and the above would require some privileges.
Aaah, I see, sorry I missed that. I'd ideally prefer the stateless, transparent mount option, but thanks for pointing out the missing kernel patch. And thanks for suggesting workarounds, I'll give them a try.
For the sake of completeness, and future reference, in case that helps anyone, I confirmed that:
Does enroot need a special argument to enable fuse? I met similar issue that enroot did not have /dev/fuse. I remember docker needs "--device /dev/fuse". I didn't see enroot manual mentions similar arguments.
Hi!
I'm trying to track down a permission issue with
enroot start
on RHEL/CentOS 7.6.All the listed requirements seem to be satisfied:
and
I can import a container just fine:
But then (as
root
):The command that fails is in
runtime::_do_mount_rootfs()
Fuse and
fusermount
work fine on that host (especially asroot
), and I can run that very same command outside ofenroot
:But I can't figure out where the EPERM in
enroot start
is coming from. Any hint to diagnose the issue and hopefully fix it would be much appreciated!Thanks!