Note that it's also possible to do this without namespaces at all, and it definitely seems to be force unmount which makes it happen.
$ fuseext2 ext2.img /tmp/d $ sudo mount --bind /tmp/d mount $ sudo umount -f mount $ ls /tmp/d ls: cannot access /tmp/d: Transport endpoint is not connected Other filesystems which implement umount_begin such as nfs also seem to start tearing down their connections in the callback, so I suspect they might behave similarly in this scenario. I'm going to test with nfs to verify. I don't really think that fuse can detect this situation. It seems like do_umount potentially needs to handle this differently in the case of a bind mount, but I'm not actually sure whether or not the behavior here is actually what's expected to happen. The other question is whether or not lxc acutally needs to use MNT_FORCE when unmounting. What's the reason for doing so? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1402834 Title: fuse filesystems get disconnected on container exit Status in linux package in Ubuntu: Confirmed Bug description: When bind-mounting a directory from a fuse filesytems into a container, then when the container is shut down, the userspace process serving the fuse fs is terminated. The original fuse mountpoint remains busy until it is manually unmounted. I've tested this with sshfs, git://github.com/stgraber/cgmanagerfs, the bbfs example fs from http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/, or git://github.com/lxc/lxcfs. To reproduce: Mount a fusefs - say sshfs - with -o allow_other, let's say onto /tmp/d. sshfs -f -d -o allow_other somehost:$HOME /tmp/d Bind that into a container by adding lxc.mount.entry = /tmp/d freezer none bind,create=dir 0 0 to the container's config. start the container, stop it. the fuse program stops (exits 0 in fact) the mount is not cleaned up - ls /tmp/d on the host henceforth complains: ls: cannot access /tmp/d Transport endpoint is not connected" (sudo umount /tmp/d cleans it up) I don't know for sure whether this is a kernel or libfuse bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402834/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
