New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow controlling the mount namespace #10088

Closed
phemmer opened this Issue Jan 14, 2015 · 11 comments

Comments

Projects
None yet
9 participants
@phemmer
Contributor

phemmer commented Jan 14, 2015

This is a continuation of a request & discussion in #6687
The primary request is to allow disabling the mount namespace inside a container. The use case is so that one container can mount a volume (real volume, not a docker volume), and then use docker volumes to share the mount with another container.
There are a few cases where you might want to do this.

  • The most obvious use case is when your container doesn't have the utilities necessary to perform the mount (mount.* missing, FUSE daemon missing, etc). You could bake the tools into the application image, but keeping them separate lets the application image remain portable.
  • A related use case is so that you can run a FUSE daemon in it's own container.
  • Another use case is if you want to share this filesystem with multiple containers simultaneously.

Currently if you mount something on top of a docker volume inside a container, and you share that volume with another container, the mount appears empty.

Since the processes inside the container need to see their root as the root of the image, we can instead use a simple chroot when the mount namespace is disabled.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 25, 2015

Contributor

+1, you could containerize things like mounting new filesystems onto the host mount namespace which can be consumed as bind-mounts for other containers as well.
Thinking things like containerized flocker.

Contributor

cpuguy83 commented Feb 25, 2015

+1, you could containerize things like mounting new filesystems onto the host mount namespace which can be consumed as bind-mounts for other containers as well.
Thinking things like containerized flocker.

@SamYaple

This comment has been minimized.

Show comment
Hide comment
@SamYaple

SamYaple Apr 5, 2015

This is also needed to access network namespaces that are created within a container due to the proc mount (typically at /run/netns/<net_namespace>).

EDIT: This is no longer a valid concern for >1.6 docker since the mount namespace is notlonger private and mount propogation works

SamYaple commented Apr 5, 2015

This is also needed to access network namespaces that are created within a container due to the proc mount (typically at /run/netns/<net_namespace>).

EDIT: This is no longer a valid concern for >1.6 docker since the mount namespace is notlonger private and mount propogation works

@denderello

This comment has been minimized.

Show comment
Hide comment
@denderello

denderello May 12, 2015

+1 We have a use case for this where mounting with a FUSE driver could be done by a seperate container.

denderello commented May 12, 2015

+1 We have a use case for this where mounting with a FUSE driver could be done by a seperate container.

@KodyKantor

This comment has been minimized.

Show comment
Hide comment
@KodyKantor

KodyKantor Jun 17, 2015

This would be great for automating the setup of filesystems within the confines of a container and then sharing it between multiple containers. +1

KodyKantor commented Jun 17, 2015

This would be great for automating the setup of filesystems within the confines of a container and then sharing it between multiple containers. +1

@rncry

This comment has been minimized.

Show comment
Hide comment
@rncry

rncry Aug 11, 2015

+1 We're also trying to use a container to mount a FUSE filesystem which needs to be shared with the host

rncry commented Aug 11, 2015

+1 We're also trying to use a container to mount a FUSE filesystem which needs to be shared with the host

@rncry

This comment has been minimized.

Show comment
Hide comment
@rncry

rncry Aug 11, 2015

There seems to be a patch here: rootfs@0ca94ce

rncry commented Aug 11, 2015

There seems to be a patch here: rootfs@0ca94ce

@btiernay

This comment has been minimized.

Show comment
Hide comment
@btiernay

btiernay Nov 5, 2015

This would be very useful in many settings for the reasons cited. Any update on this?

btiernay commented Nov 5, 2015

This would be very useful in many settings for the reasons cited. Any update on this?

@rhatdan

This comment has been minimized.

Show comment
Hide comment
@rhatdan

rhatdan Nov 5, 2015

Contributor

We are close. Checkout.

#17034

Contributor

rhatdan commented Nov 5, 2015

We are close. Checkout.

#17034

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Nov 5, 2015

Member

@phemmer would #17034 fully address this? If so, could you make sure that a fixes ... is added to the PR description @rhatdan?

Member

thaJeztah commented Nov 5, 2015

@phemmer would #17034 fully address this? If so, could you make sure that a fixes ... is added to the PR description @rhatdan?

@phemmer

This comment has been minimized.

Show comment
Hide comment
@phemmer

phemmer Nov 5, 2015

Contributor

Yes. Could also just close this as a dup of #14630

Contributor

phemmer commented Nov 5, 2015

Yes. Could also just close this as a dup of #14630

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Nov 5, 2015

Member

Cool, I'll close this one, thanks @phemmer ! (technically it's the other way around, because this one's older, but 👍)

Member

thaJeztah commented Nov 5, 2015

Cool, I'll close this one, thanks @phemmer ! (technically it's the other way around, because this one's older, but 👍)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment