Adding a shared host directory to an LXC/LXD Container












15















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.










share|improve this question


















  • 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 '15 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?)

    – David Foerster
    Feb 12 '17 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.

    – 0xC0000022L
    Nov 23 '17 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 '18 at 17:21
















15















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.










share|improve this question


















  • 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 '15 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?)

    – David Foerster
    Feb 12 '17 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.

    – 0xC0000022L
    Nov 23 '17 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 '18 at 17:21














15












15








15


12






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.










share|improve this question














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.







lxc lxd






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Oct 28 '15 at 12:39









user47227user47227

1471111




1471111








  • 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 '15 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?)

    – David Foerster
    Feb 12 '17 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.

    – 0xC0000022L
    Nov 23 '17 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 '18 at 17:21














  • 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 '15 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?)

    – David Foerster
    Feb 12 '17 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.

    – 0xC0000022L
    Nov 23 '17 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 '18 at 17:21








2




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 '15 at 13:01







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 '15 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?)

– David Foerster
Feb 12 '17 at 13:36





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?)

– David Foerster
Feb 12 '17 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.

– 0xC0000022L
Nov 23 '17 at 15:46





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.

– 0xC0000022L
Nov 23 '17 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 '18 at 17:21





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 '18 at 17:21










4 Answers
4






active

oldest

votes


















16














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.






share|improve this answer

































    3














    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



    • Additional notes on configuration: https://help.ubuntu.com/lts/serverguide/lxd.html






    share|improve this answer
























    • 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.

      – nobar
      Sep 23 '17 at 6:25













    • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

      – nobar
      Sep 23 '17 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

      – nobar
      Sep 23 '17 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!

      – 0xC0000022L
      May 14 '18 at 9:15



















    2














    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





    share|improve this answer


























    • 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.)

      – David Foerster
      Feb 12 '17 at 13:36



















    0














    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:



    https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8






    share|improve this answer





















    • 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 '15 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 '16 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

      – David Foerster
      Feb 12 '17 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 '17 at 9:04











    • What's so hard about using either ACLs or the method outlined here?

      – 0xC0000022L
      May 14 '18 at 9:17











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f691039%2fadding-a-shared-host-directory-to-an-lxc-lxd-container%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    16














    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.






    share|improve this answer






























      16














      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.






      share|improve this answer




























        16












        16








        16







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 23 '17 at 15:44









        0xC0000022L

        3,00853770




        3,00853770










        answered Mar 5 '16 at 21:42









        ph0t0nixph0t0nix

        1,0771025




        1,0771025

























            3














            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



            • Additional notes on configuration: https://help.ubuntu.com/lts/serverguide/lxd.html






            share|improve this answer
























            • 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.

              – nobar
              Sep 23 '17 at 6:25













            • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

              – nobar
              Sep 23 '17 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

              – nobar
              Sep 23 '17 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!

              – 0xC0000022L
              May 14 '18 at 9:15
















            3














            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



            • Additional notes on configuration: https://help.ubuntu.com/lts/serverguide/lxd.html






            share|improve this answer
























            • 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.

              – nobar
              Sep 23 '17 at 6:25













            • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

              – nobar
              Sep 23 '17 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

              – nobar
              Sep 23 '17 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!

              – 0xC0000022L
              May 14 '18 at 9:15














            3












            3








            3







            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



            • Additional notes on configuration: https://help.ubuntu.com/lts/serverguide/lxd.html






            share|improve this answer













            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



            • Additional notes on configuration: https://help.ubuntu.com/lts/serverguide/lxd.html







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Sep 23 '17 at 5:47









            nobarnobar

            1,52121427




            1,52121427













            • 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.

              – nobar
              Sep 23 '17 at 6:25













            • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

              – nobar
              Sep 23 '17 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

              – nobar
              Sep 23 '17 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!

              – 0xC0000022L
              May 14 '18 at 9:15



















            • 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.

              – nobar
              Sep 23 '17 at 6:25













            • Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

              – nobar
              Sep 23 '17 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

              – nobar
              Sep 23 '17 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!

              – 0xC0000022L
              May 14 '18 at 9:15

















            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.

            – nobar
            Sep 23 '17 at 6:25







            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.

            – nobar
            Sep 23 '17 at 6:25















            Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

            – nobar
            Sep 23 '17 at 21:39





            Regarding http_proxy, I think the easier solution is probably to enable IPV4 as discussed here.

            – nobar
            Sep 23 '17 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

            – nobar
            Sep 23 '17 at 22:56





            ... 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

            – nobar
            Sep 23 '17 at 22:56




            1




            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!

            – 0xC0000022L
            May 14 '18 at 9:15





            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!

            – 0xC0000022L
            May 14 '18 at 9:15











            2














            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





            share|improve this answer


























            • 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.)

              – David Foerster
              Feb 12 '17 at 13:36
















            2














            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





            share|improve this answer


























            • 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.)

              – David Foerster
              Feb 12 '17 at 13:36














            2












            2








            2







            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





            share|improve this answer















            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






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 5 at 19:27









            anatoly techtonik

            84121431




            84121431










            answered Feb 12 '17 at 10:41









            Guest8354542556745Guest8354542556745

            212




            212













            • 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.)

              – David Foerster
              Feb 12 '17 at 13:36



















            • 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.)

              – David Foerster
              Feb 12 '17 at 13:36

















            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.)

            – David Foerster
            Feb 12 '17 at 13:36





            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.)

            – David Foerster
            Feb 12 '17 at 13:36











            0














            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:



            https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8






            share|improve this answer





















            • 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 '15 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 '16 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

              – David Foerster
              Feb 12 '17 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 '17 at 9:04











            • What's so hard about using either ACLs or the method outlined here?

              – 0xC0000022L
              May 14 '18 at 9:17
















            0














            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:



            https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8






            share|improve this answer





















            • 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 '15 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 '16 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

              – David Foerster
              Feb 12 '17 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 '17 at 9:04











            • What's so hard about using either ACLs or the method outlined here?

              – 0xC0000022L
              May 14 '18 at 9:17














            0












            0








            0







            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:



            https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8






            share|improve this answer















            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:



            https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 16 '17 at 9:02

























            answered Oct 28 '15 at 13:33









            user47227user47227

            1471111




            1471111








            • 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 '15 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 '16 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

              – David Foerster
              Feb 12 '17 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 '17 at 9:04











            • What's so hard about using either ACLs or the method outlined here?

              – 0xC0000022L
              May 14 '18 at 9:17














            • 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 '15 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 '16 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

              – David Foerster
              Feb 12 '17 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 '17 at 9:04











            • What's so hard about using either ACLs or the method outlined here?

              – 0xC0000022L
              May 14 '18 at 9:17








            5




            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 '15 at 17:46





            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 '15 at 17:46




            1




            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 '16 at 12:26





            @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 '16 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

            – David Foerster
            Feb 12 '17 at 13:37





            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

            – David Foerster
            Feb 12 '17 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 '17 at 9:04





            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 '17 at 9:04













            What's so hard about using either ACLs or the method outlined here?

            – 0xC0000022L
            May 14 '18 at 9:17





            What's so hard about using either ACLs or the method outlined here?

            – 0xC0000022L
            May 14 '18 at 9:17


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f691039%2fadding-a-shared-host-directory-to-an-lxc-lxd-container%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Mouse cursor on multiple screens with different PPI

            Agildo Ribeiro

            Sometime when accessing a menu: “Ubuntu 16.04 has experienced an internal error”