Mounting in running container

Hi!
After capabilities have been introduced, I thought it is now possible to mount external folders (from the host or remote machine with SSHFS) inside running containers without use of --privileged. Am I wrong?

I run Docker 1.3.1 and I cannot mount without --privileged.
Here is a similar issue: #6535

Kind regards,
Peter

Mount requires CAP_SYS_ADMIN, which is not allowed in the default container.
You should be able to do this with "docker run --cap-add SYS_ADMIN

this comes up often enough that we should add an example to the docs.

Thank you for your answers!
I still get error when trying to mount host folder with sshfs.

Inside container started with --cap-add SYS_ADMIN:

root@cf3107829835:/# sshfs user@172.17.42.1:/home/user /mnt
fuse: failed to open /dev/fuse: Operation not permitted

With --privileged it works.

Are you on a system like ubuntu that has apparmor? This could be apparmor blocking the mount, you can look in dmesg and you should see the apparmor blocking this call.

My host has Ubuntu 12.04.
I put apparmor docker-default profile into complain mode:

peter@poweredge320:~$ sudo apparmor_status
apparmor module is loaded.
9 profiles are loaded.
8 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/named
   /usr/sbin/ntpd
   /usr/sbin/tcpdump
   lxc-container-default
1 profiles are in complain mode.
   docker-default
3 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/named (1359)
   /usr/sbin/ntpd (1155)
1 processes are in complain mode.
   docker-default (16864)
0 processes are unconfined but have a profile defined.

But still when I start container with --cap-add SYS_ADMIN I cannot use sshfs:

root@e76cafc2dc34:/# sshfs peter@172.17.42.1:/home/peter/ /mnt
fuse: failed to open /dev/fuse: Operation not permitted

In dmesg I see lots of messages like this:

[1950461.070715] type=1400 audit(1417657285.832:282): apparmor="ALLOWED" operation="file_mmap" info="Failed name lookup" error=-13 parent=11128 profile="docker-default" name="var/lib/docker/aufs/diff/5bc37dc2dfba434d7551fa17ee9d3ebba6adab648cebc2f962e612855c4c580c/lib/x86_64-linux-gnu/libdl-2.19.so" pid=17038 comm="bash" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0

When docker-default was in enforce mode, I didn't see docker-related messages in dmesg.

In container started with --privileged I can mount host folders with sshfs.

You should try adding --device /dev/fuse, too.

Thank you, Tianon!
Added --device /dev/fuse and voilà:

peter@poweredge320:~$ docker run -ti --cap-add SYS_ADMIN --device /dev/fuse peter/dev:sshfs /bin/bash
root@26cf4dc0a491:/# sshfs peter@172.17.42.1:/home/peter /mnt
peter@172.17.42.1's password:
...

By the way, without --cap-add SYS_ADMIN the error message is different (was "fuse: failed to open /dev/fuse: Operation not permitted" before):

11:36:26peter@poweredge320:~$ docker run -ti --name dev --device /dev/fuse peter/dev:sshfs /bin/bash
root@1d49112eaf95:/# sshfs peter@172.17.42.1:/home/peter/ /mnt
fusermount: mount failed: Permission denied

Thank you all for your help!

The final answer:
Use --cap-add SYS_ADMIN --device /dev/fuse to mount folders with sshfs in container.

Going to close this then, glad everything is working :)

reopening as it really needs docs.

@SvenDowideit

Assigning to @SvenDowideit so hopefully this does not sit open for a long long time.

My bad - my client was v1.9.1. When I flipped back to v1.10 it works just fine. Thank you! 😁

Do you happen to know how I can start an already existing container with those flags?
I tried using "docker start container_name --privileged --cap-add=MKNOD --cap-add=SYS_ADMIN --device=/dev/fuse" but I'm unable to use those flags with the start command.
With the docker run command it creates a new container that I then have to re-setup.

@Rick7C2

@Rick7C2 you can't, you need to start a new container with those options. Depending on your use case, you can start a privileged session in an existing container through docker exec -it --privileged <container> bash

The comments about seccomp:unconfined above might be out of date. As mentioned in #16429 you need apparmor:unconfined to mount fuse volumes in a container. You should not need to use --privileged.

$ docker run -ti --cap-add SYS_ADMIN --cap-add MKNOD --device=/dev/fuse --security-opt apparmor:unconfined centos bash

Was able to get it working with:

docker run -ti --privileged --cap-add SYS_ADMIN --cap-add MKNOD --device=/dev/fuse --security-opt apparmor:unconfined ubuntu-fuse

and

docker exec -ti --privileged <container_id> bash -l

ubuntu-fuse is based off phusion/baseimage-docker

I'm new to Docker so it's possible some of the args are redundant, except --priviledged, it doesn't work without it in docker run. Also followed instructions here, not sure if that's relevant or not.

Sorry to open this again, is it not possible to add these to Dockerfile so that we can prevent writing each time we are running it?

@sarpk

@sarpk no; a container / image itself should not be able to gain privileges by itself; that would really be dangerous because simply running that image would give it root access to your host; and basically remove all the isolation / security that containers bring. Giving privileges needs to be an explicit action, that you set at runtime (on docker run)

--cap-add SYS_ADMIN --device=/dev/fuse --security-opt apparmor:unconfined works for me without --privileged in Ubuntu.

docker run -it --cap-add MKNOD --cap-add SYS_ADMIN --device /dev/fuse works for centos 7.0 with Docker 17.05.0-ce

On ubuntu 16.04, I needed to disable apparmor to use fuse

Disable apparmor to use fuse

Any idea how to do this without the dangerous CAP_SYS_ADMIN?
I've tried explicitly defining a policy, and putting mount/umount/umount2 in the allowed calls, but it still doesn't work unless I --cap-add=SYS_ADMIN. Strace says the mount() call is getting EPERM :(

Being able to use fuse without SYS_ADMIN would be very helpful, this is needed for running AppImages inside docker.

--security-opt="seccomp=unconfined" kernel mount
--cap-add=SYS_ADMIN kernel and fuse
--device /dev/fuse fuse mount

use kernel module mount cephfs

[root@mon-mds-mgr-01 ~]# docker run -it --security-opt="seccomp=unconfined"   --cap-add=SYS_ADMIN  --device /dev/fuse registry.xxx.cn/public/centos7-fuse:latest bash
[root@94cb5768fb17 /]# mkdir mount1
[root@94cb5768fb17 /]# mount -t ceph mon-mds-mgr-01:6789,mon-mds-mgr-02:6789,mon-mds-mgr-03:6789:/dir1 -o name=admin,secret=AQCncLpe,fs=fs-002 ./mount1/
failed to load ceph kernel module (1)
[root@94cb5768fb17 /]# df -h
Filesystem                                                Size  Used Avail Use% Mounted on
overlay                                                    36G  7.8G   28G  23% /
tmpfs                                                      64M     0   64M   0% /dev
tmpfs                                                     3.9G     0  3.9G   0% /sys/fs/cgroup
shm                                                        64M     0   64M   0% /dev/shm
/dev/mapper/centos-root                                    36G  7.8G   28G  23% /etc/hosts
tmpfs                                                     3.9G     0  3.9G   0% /proc/acpi
tmpfs                                                     3.9G     0  3.9G   0% /proc/scsi
tmpfs                                                     3.9G     0  3.9G   0% /sys/firmware
10.16.19.21:6789,10.16.19.22:6789,10.16.19.23:6789:/dir1  474G     0  474G   0% /mount1

with fuse mount also is very good

Navigation Menu

Repository navigation

Mounting in running container #9448

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Mounting in running container #9448

Description

Activity

cpuguy83 commented on Dec 2, 2014

SvenDowideit commented on Dec 3, 2014

pyotr777 commented on Dec 3, 2014

crosbymichael commented on Dec 3, 2014

pyotr777 commented on Dec 4, 2014

tianon commented on Dec 4, 2014

pyotr777 commented on Dec 4, 2014

jessfraz commented on Dec 4, 2014

SvenDowideit commented on Dec 4, 2014

crosbymichael commented on Dec 4, 2014

18 remaining items

hairyhenderson commented on Feb 3, 2016

Rick7C2 commented on Apr 24, 2016

thaJeztah commented on Apr 24, 2016

jamshid commented on May 24, 2016

sent-hil commented on May 29, 2016

sarpk commented on Sep 25, 2016

thaJeztah commented on Sep 25, 2016

tobegit3hub commented on Mar 29, 2017

ZongqiangZhang commented on May 17, 2017

manos commented on Mar 9, 2018

omeid commented on Jul 18, 2019

klzsysy commented on May 16, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions