fuse filesystems get disconnected on container exit
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
Medium
|
Seth Forshee |
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.
the bbfs example fs from http://
or git://github.
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.
Changed in linux (Ubuntu): | |
assignee: | nobody → Seth Forshee (sforshee) |
importance: | Undecided → Medium |
status: | New → In Progress |
status: | In Progress → Confirmed |
tags: | added: kernel-da-key |
The big question is whether we tried to unmount the mount to trigger the exit. If we just killed the fuse server then the kernel behaviour seems valid. If we attempted to unmount it, that let the server go, then the umount failed, that sounds wrong.