19

How can I share a folder between the host system (ubuntu 14.04) and an ubuntu lxc container?

I tried mounting the folder on the host:

sudo mount --bind /media/data/share /media/data/container/name/rootfs/share

but I can't see any files.

The same goes for:

sudo ln -s /media/data/share /media/data/container/name/rootfs/share

Do I need to change permissions for the share folder?

Jorge Castro
  • 70,934
  • 124
  • 466
  • 653
Max
  • 361
  • 1
  • 2
  • 7

4 Answers4

16

According to the LXC documentation you can do this via a privileged container:

lxc launch ubuntu priv -c security.privileged=true
lxc config device add priv homedir disk source=/home/$USER path=/home/ubuntu
jgomo3
  • 716
  • 1
  • 9
  • 23
Jorge Castro
  • 70,934
  • 124
  • 466
  • 653
  • Note that, that is the LXD documentation, not LXC. If you haven't installed LXD, then the lxc command won't work. – Sam Bull Jul 15 '17 at 17:50
  • @SamBull well, this is self-inflicted by the LXC/LXD team. LXC can be used to refer to liblxc (the underlying library) or to the LXD client (named `lxd`) as used in this answer or to LXC (the software and "old" toolset with the `lxc-*`-named tools) or to the project (where LXC is short for LinuX Containers). It's the reason I asked [this question](https://unix.meta.stackexchange.com/q/4694/5462) on the Unix.SE meta. – 0xC0000022L May 14 '18 at 09:03
  • The above requires a privileged container, but for better security separation, you can instead use `lxc config device ... shift=true` and then, if you get the "isn't supported error", `sudo snap set lxd shiftfs.enable=true && sudo systemctl reload snap.lxd.daemon` and retry `lxc config ...`. – bitinerant Mar 16 '21 at 22:18
  • @bitinerant Feel free to just submit an edit to my answer to make it correct, thanks! – Jorge Castro Mar 30 '21 at 18:54
15

I found an article in the openSUSE wiki: https://en.opensuse.org/User:Tsu2/LXC_mount_shared_directory

I followed the steps and it works now.

Create host directory:

mkdir /media/data/share && chmod 7777 /media/data/share

Create directory in lxc container:

mkdir /share

Edit lxc config file on host:

nano /var/lib/lxc/containername/config
lxc.mount.entry = /media/data/share share none ro,bind 0.0
Max
  • 361
  • 1
  • 2
  • 7
  • Is there a reason behind defining that mount entry as read only? Is that a good security practice to avoid a container to write back data to a shared filesystem?. – jgomo3 Mar 30 '16 at 19:48
  • 1
    Worked for me. Note that the relative path used for `share` in the `lxc.mount.entry` is critical. – HRJ Dec 01 '16 at 11:36
  • 2
    You don't need to create the mount point, if you add ',create=dir' after 'bind'. I've also removed the 'ro,' part, and it seems to be working just fine. – Sam Bull Jul 15 '17 at 18:06
4

Below is what I have done to mount one of my host directory to the container. This is trickier than it sounds because we would like to achieve

  • Inside the container we should be able to write to the directory.
  • Outside the container we should be able to write to the files and directories created inside the container.

After reading various articles online (the most helpful one is this github issue), here is how I solve this. The trick is to map the uid and gid of the host user to the uid and gid of the user inside the container.

Suppose I am going to mount /home/breakds/projects to the exact same location in the container. The outside directory is owned by the user breakds, whose uid and gid are 1000.

I then created an user in the container called debian, whose uid and gid happened to be 1000 as well (because it is the first non root user). I will then create an (lxc) profie on the host by

lxc profile edit breakds

And below is the content of the profile (I believe it is in yaml format):

name: breakds
config:
    raw.lxc: |
        lxc.id_map =
        lxc.id_map = u 0 165536 999
        lxc.id_map = g 0 165536 999
        lxc.id_map = u 1000 1000 1
        lxc.id_map = g 1000 1000 1
        lxc.id_map = u 1001 166537 64535
        lxc.id_map = g 1001 166537 64535
    user.vendor-data: |
        packages:
            - bash
description: allow home dir mounting for breakds
devices:
eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
projects:
    path: /home/breakds/projects
    source: /home/debian/projects
    type: disk

Then, apply this profile to that container permanently:

$ lxc profile apply <my container> breakds

This should do the trick.

NOTE: Please note that before switching to this profile, make sure that all direcotries or files whose owner/group is debian should be deleted (and probably recreated after the switch). This is because after the uid and gid mapping, their ownership will become invalid. I originally thought since I am just mapping 1000 to 1000 everything should be fine, but I think I missed something here and it would be great if some one can advice on how to resolve this without the hack.

BreakDS
  • 141
  • 3
1

You can also do this without LXD by editing the LXC config file directly:

# Container specific configuration
lxc.idmap = u 0 165536 1000
lxc.idmap = g 0 165536 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = g 1000 1000 1
lxc.idmap = u 1001 166536 64535
lxc.idmap = g 1001 166536 64535

You also have to make sure that the container's user's account is given permission to map to uid/gid 1000 on the host by editing /etc/subuid and /etc/subgid:

containeruser:165536:65536
containeruser:1000:1
apokluda
  • 79
  • 1
  • 7