> On October 7, 2016 at 11:45 AM Stéphane Graber <[email protected]> wrote: > > > On Fri, Oct 07, 2016 at 07:03:21AM +0000, Jäkel, Guido wrote: > > Dear experts, > > > > I wonder if it's possible to establish a bind mount filesystem resource > > from the LXC host to an already running container in an manual way, but > > analogous as it is done at startup time. > > > > I already figured out that the releasing an existing link is no thing; just > > umount it from inside the container. But is there a way to establish one > > while shifting the destination of a bind mount into the right namespace? > > > > I ask about, because in a couple of days I have to change a (NFS) > > filesystem source (because of an hardware migration) that is common to a > > large number of running containers but not frequently used and I want to > > avoid to restart all the containers with it services. > > > > thank you for advice > > > > Guido > > It's very difficult due to a number of restrictions in place in the kernel. > > The only way of doing this that I'm aware of is what we do in LXD. We > create a path on the host before the container starts, put that on a > rshared mountpoint, then bind-mount that directory into the container > under some arbitrary path.
But the container can break this from the inside by turning the inner slave mount point into a private mountpoint once (which cannot be undone). Then again, the standard AppArmor profile still has the make-private on ** rules commented out with the note that AppArmor treats it as allowing all mounts, so I suppose in the default case it'll be hard to break this functionality. I've been wondering if there's a more reliable way for a while now... _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
