I have been experimenting with LXC/LXD on Ubuntu 14.04 and it's all working great. I just need to figure out how to get shared directories working between my host machine and a container so I can ditch Virtualbox once and for all.

I have seen this page: https://wiki.gentoo.org/wiki/LXD

Which provides instructions, but I just keep getting errors.

Does anyone know of any simple, clear instructions to get this working? Any help much appreciated.

  • 2
    I've managed to mount a host directory using: lxc config device add confexample sharedtmp disk path=/tmp source=/tmp/shared. But looking at the directory on the container the owner and group for the files in there are set to 'nobody' and 'nogroup' and the mount is read only.
    – user47227
    Oct 28, 2015 at 13:01
  • Could you please add a little more detail? What exactly did you do, what did you want to achieve and what happened instead? Did you encounter any warning or error messages? Please reproduce them in their entirety in your question. You can select, copy and paste terminal content and most dialogue messages in Ubuntu. (see How do I ask a good question?) Feb 12, 2017 at 13:36
  • Assuming you're using an unprivileged container and the UID/GID mapping is the issue, have a look at this section of an article about the userns mappings with LXD. However, this was probably added into LXD way after you asked your question. Nov 23, 2017 at 15:46
  • I don't know which version added this (I'm on 2.18) but if possible, you could also use the lxc file to transfer files between host and container, using push and pull.
    – code_dredd
    Apr 13, 2018 at 17:21

5 Answers 5


The instructions on https://wiki.gentoo.org/wiki/LXD that you mention are correct but may need a bit more explanation.

On the host you first check the ownership of the directory in which the container data is stored. Run

sudo ls -l /var/lib/lxd/containers

and check the owner of the container you would like to share the directory with. In my case the uid and gid both were 100000.

Next, use these to change the ownership of the directory you want to share:

sudo chown 100000:100000 /tmp/share_on_host

Share the directory with the container in the way you indicated in your comment:

lxc config device add mycontainer sharedtmp disk \
                  path=/tmp/share_on_guest source=/tmp/share_on_host

Now, in the container, you will see that the directory /tmp/share_on_guest (I wouldn't advise to mount your directory as /tmp because that is used by the system for other stuff and has special permissions) is owned by root. From here on you can use chown in the container to change the ownership to the appropriate uid and gid for your user in the container.

As a side note, after changing the ownership in the container to e.g. a user with uid 33 you will see on the host that the uid there is now 100033, which makes total sense.

  • Not sure if it's just my setup, but with LXD v3.0.3 LTS (Ubuntu 18.04 LTS) I found nothing but symbolic links within /var/lib/lxd/containers that pointed over to /var/lib/lxd/storage-pools/lxd/containers (in this case the last lxd bit is the name of my ZFS storage pool). All containers there seemed to have the same 165536 uid/gid when running and owned by root:root when off.
    – deoren
    Mar 17, 2019 at 21:42
  • 2
    I realize this is an old question + answer, but in Ubuntu 18.04, I did not have to mess with any permission whatsoever. Just add the folder with lxc config and it worked like a charm!
    – Apache
    Sep 20, 2019 at 19:06

Here is an updated answer to this question.

Mount the host folder /var/www as /var/test in the container.

lxc config device add mycontainer vartest disk source=/var/www path=/var/test
  • Welcome to Ask Ubuntu! I recommend editing this answer to expand it with specific details about how to do this. (See also How do I write a good answer? for general advice about what sorts of answers are considered most valuable on AskUbuntu.) Feb 12, 2017 at 13:36

You can assign additional devices to the container, and these can be host-accessible folders.

$ lxc config ## display help
lxc config device add [<remote>:]<container> <device> <type> [key=value...]
    Add a device to a container.

Note that <device> is just an arbitrary name that you assign, which will be used as an ID for subsequent device management.

For example, to mount the host folder "./host" as "/mnt/host" in the container...

lxc config device add mycontainer vartest disk source=$(pwd)/host path=/mnt/host

There remains one problem -- if you want this folder to be writable by both the host and the container, the ownership and permissions need to be configured accordingly. This is complicated by the default mode of LXD which virtualizes the numeric ranges for user and group id values. There is an easy solution, however: bypass this virtualization by configuring the container to run with host-equivalent privileges...

lxc config set <container> security.privileged true

The full host-security implications of this approach are unclear to me at this time, but would seem to be somewhat "contained" by the virtualization. The practical risk depends on how and why you will be using the container. See technical notes at https://insights.ubuntu.com/2017/06/15/custom-user-mappings-in-lxd-containers

Further note that this approach probably works best if you normally operate in the container as a non-root user, such as if you attach with...

lxc exec zesty -- su --login ubuntu
  • There's a problem with the non-root login: The env is different, in particular http_proxy. An example workaround: sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update. Sep 23, 2017 at 6:25
  • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here. Sep 23, 2017 at 21:39
  • ... followed by sudo dhclient in the container -- or change manual to dhcp in 50-cloud-init.cfg. Nice clues here: github.com/lxc/lxd/issues/1298 Sep 23, 2017 at 22:56
  • 1
    This is a patently bad idea. Recommending to switch to privileged containers subverts one of the very advances LXD brought. While LXC 1.x also offered the possibility to use unprivileged containers (and yes, even as root), it was a tad bit more complicated to sort out the details. With LXD this is now a thing of the past. Besides, what's so complicated about setting ACLs on some folder to allow the host-side UID the required access or to use the method outlined here? Yeah mapping UIDs/GIDs isn't the only way! May 14, 2018 at 9:15

Based on the excellent answer of ph0t0nix, I propose the following step-by-step approach for my Ubuntu 18.04 server:

  1. In host determine UID of owner of rootfs:

    sudo ls -l /var/lib/lxd/storage-pools/lxd/containers/webserver/rootfs  
    id -u root   → 100000
  2. In container determine UID of ubuntu (i.e. user in container):

    id -u ubuntu   → 1000
  3. Create shared folder in host and add it to container:

    lxc config device add webserver mydevicename disk path=/home/share_on_guest source=/home/share_on_host
  4. Adjust in host UID of shared folder (UID = UID host + UID guest):

    sudo chown 101000:101000 /home/share_on_host
  5. Guest (user ubuntu) has now access to shared folder and can adjust within container access to shared folder using chmod.


I now have a working, safe solution to this issue, using LXD profiles to handle the mapping between UID and GID in the container and on the host.

A very useful gist may be found here:


  • 5
    Note that making things world-writable is usually a bad idea from a security point of view. You probably should look into using POSIX ACLs on the host path, granting access to the container's user by adding a specific ACL for that uid, and then for any other host user which also needs write access.
    – stgraber
    Nov 23, 2015 at 17:46
  • 1
    @stgraber while I agree with what you said, I have no idea how to set that up. Some links would be helpful.
    – s3v3n
    Aug 11, 2016 at 12:26
  • Please don't recommend 0777 a.k.a. “please-hack-my-system-and-destroy-my-data” permissions for no apparent reason! There's almost never a reason to to that because it can be avoided with more sensible modifications like changing (group) ownership. -1 Feb 12, 2017 at 13:37
  • I take your point, but I only used that as a temporary workaround on a single user development machine, in the absence of any other way to get it working. Since then I have discovered that using profiles is the way to handle this, see my edited answer above!
    – user47227
    Feb 16, 2017 at 9:04
  • 1
    What's so hard about using either ACLs or the method outlined here? May 14, 2018 at 9:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .