FUSE inside Docker

Question

I'm trying to install and use FUSE inside a Docker container. My Dockerfile is the following:

FROM golang:1.8

WORKDIR /go/src/app
COPY . .

RUN apt-get update && apt-get install -y fuse && rm -rf /var/lib/apt/lists/*
RUN go-wrapper download
RUN go-wrapper install

CMD ["go-wrapper", "run", "/mnt"]

When I run the program mounting FUSE, I get: /bin/fusermount: fuse device not found, try 'modprobe fuse' first.

If I install kmod and run modprobe fuse during the build step, I get the error:

modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.104-boot2docker/modules.dep.bin'

How can I fix this?

Millian

How do you run the container? Do you specify --privileged mode? – Yuu

I use docker run -it --rm. Adding --privileged does not help with the modprobe error message, nor with the FUSE one. – Millian

Answer 1

With respect to Nickolay's answer below, the --privileged flag is not strictly required, for fuse. And you're best to avoid giving that much privilege to your container.

You should be able to get things working by replacing it with --cap-add SYS_ADMIN like below.

docker run -d --rm \
           --device /dev/fuse \
           --cap-add SYS_ADMIN \
      <image_id/name>

Sometimes this may not work. In this case, you should try and tweak the AppArmor profile or just disable it as follows:

docker run -d --rm \
           --device /dev/fuse \
           --cap-add SYS_ADMIN \
           --security-opt apparmor:unconfined \
      <image_id/name>

Finally, if all fails, use --privileged flag.

Fractostratus

Isn't the SYS_ADMIN cap basically equivalent to running the container in privileged mode? – Transferase

@Transferase SYS_ADMIN is one of the things --privileged adds, but --privileged also removes a lot more protections Docker provides by default (default cgroups, seccomp profiles, etc etc etc) such that the net result is that specifying --cap-add SYS_ADMIN is much more secure than --privileged – Deluge

I think --device /dev/fuse should not be included in the docker run cmd. That gives the container access to the host's /dev/fuse, which is not what was requested, IIUC. – Headmistress

@GenericRatzlaugh It's the same kernel and, thus, the same /dev/fuse. (Device files are basically just aliases for kernel interfaces.) You need it to interface with FUSE but you can then use user namespaces to add isolation starting with kernel version 4.18. See docker/for-linux#321 for details. – Townshend

@nickgryg response about using --device /dev/fuse is better – Apathy

Answer 2

Just as a workaround you can do the modprobe fuse on your host, then using --device /dev/fuse to get the device in the container. Anyway container should be started in privileged mode to mount things with the /dev/fuse.

The command to run the docker image is:

docker run -d --rm --device /dev/fuse --privileged <image_id/name>

Saadi

Thanks for the workaround. Ideally, I would like it to work on OSX too and I don't know if there's any way to emulate /dev/fuse on it. – Millian

This is probably the solution, as a docker jail does not run its own kernel, so you need to have the module loaded outside of the jail and the device access allowed by the host. Take care and check if the fuse device can be used to break out of the jail. – Odds

I know I'm late to the party but re: /dev/fuse on OS X, Fuse for OS X works great and can be installed via brew: brew install osxfuse or osxfuse.github.io – Giuseppe

As Gary notes above, the --privileged option should be used very carefully. More details (on the risks) in this Medium post: medium.com/lucjuggery/… – Moribund

is there a non-paywalled version of that post, @Drew? – Bertrambertrand