44

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?

Cydonia7
  • 3,744
  • 2
  • 23
  • 32

2 Answers2

63

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.

Drew
  • 6,311
  • 4
  • 44
  • 44
Gery Vessere
  • 871
  • 5
  • 9
  • 2
    Isn't the SYS_ADMIN cap basically equivalent to running the container in privileged mode? – Ibrahim Apr 18 '19 at 18:00
  • 5
    @Ibrahim 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 – tianon Oct 18 '19 at 23:49
  • 4
    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. – Generic Ratzlaugh Sep 08 '20 at 21:09
  • 4
    @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](https://github.com/docker/for-linux/issues/321) for details. – ssokolow Sep 17 '20 at 07:48
  • @nickgryg response about using --device /dev/fuse is better – 8znr Mar 18 '21 at 14:29
5

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>
nickgryg
  • 25,567
  • 5
  • 77
  • 79
  • 1
    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. – Cydonia7 Jan 28 '18 at 22:20
  • 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. – allo Jan 31 '18 at 14:44
  • 1
    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 https://osxfuse.github.io/ – Chaim Eliyah Jun 17 '19 at 03:06
  • As Gary notes above, the --privileged option should be used very carefully. More details (on the risks) in this Medium post: https://medium.com/lucjuggery/docker-tips-mind-the-privileged-flag-d6e2ae71bdb4 – Drew Aug 02 '19 at 17:58
  • is there a non-paywalled version of that post, @Drew? – lahwran Sep 25 '21 at 21:27