Adding a shared host directory to an LXC/LXD Container
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
add a comment |
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
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 thelxc fileto transfer files between host and container, usingpushandpull.
– code_dredd
Apr 13 '18 at 17:21
add a comment |
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
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
lxc lxd
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 thelxc fileto transfer files between host and container, usingpushandpull.
– code_dredd
Apr 13 '18 at 17:21
add a comment |
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 thelxc fileto transfer files between host and container, usingpushandpull.
– 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
add a comment |
4 Answers
4
active
oldest
votes
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.
add a comment |
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
There's a problem with the non-root login: Theenvis different, in particularhttp_proxy. An example workaround:sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
– nobar
Sep 23 '17 at 6:25
Regardinghttp_proxy, I think the easier solution is probably to enable IPV4 as discussed here.
– nobar
Sep 23 '17 at 21:39
... followed bysudo dhclientin the container -- or changemanualtodhcpin50-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
add a comment |
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.)
– David Foerster
Feb 12 '17 at 13:36
add a comment |
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
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 recommend0777a.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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 23 '17 at 15:44
0xC0000022L
3,00853770
3,00853770
answered Mar 5 '16 at 21:42
ph0t0nixph0t0nix
1,0771025
1,0771025
add a comment |
add a comment |
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
There's a problem with the non-root login: Theenvis different, in particularhttp_proxy. An example workaround:sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
– nobar
Sep 23 '17 at 6:25
Regardinghttp_proxy, I think the easier solution is probably to enable IPV4 as discussed here.
– nobar
Sep 23 '17 at 21:39
... followed bysudo dhclientin the container -- or changemanualtodhcpin50-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
add a comment |
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
There's a problem with the non-root login: Theenvis different, in particularhttp_proxy. An example workaround:sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
– nobar
Sep 23 '17 at 6:25
Regardinghttp_proxy, I think the easier solution is probably to enable IPV4 as discussed here.
– nobar
Sep 23 '17 at 21:39
... followed bysudo dhclientin the container -- or changemanualtodhcpin50-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
add a comment |
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
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
answered Sep 23 '17 at 5:47
nobarnobar
1,52121427
1,52121427
There's a problem with the non-root login: Theenvis different, in particularhttp_proxy. An example workaround:sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
– nobar
Sep 23 '17 at 6:25
Regardinghttp_proxy, I think the easier solution is probably to enable IPV4 as discussed here.
– nobar
Sep 23 '17 at 21:39
... followed bysudo dhclientin the container -- or changemanualtodhcpin50-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
add a comment |
There's a problem with the non-root login: Theenvis different, in particularhttp_proxy. An example workaround:sudo http_proxy=http://[fe80::1%eth0]:13128 apt-get update.
– nobar
Sep 23 '17 at 6:25
Regardinghttp_proxy, I think the easier solution is probably to enable IPV4 as discussed here.
– nobar
Sep 23 '17 at 21:39
... followed bysudo dhclientin the container -- or changemanualtodhcpin50-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
add a comment |
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.)
– David Foerster
Feb 12 '17 at 13:36
add a comment |
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.)
– David Foerster
Feb 12 '17 at 13:36
add a comment |
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
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
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
add a comment |
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
add a comment |
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
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 recommend0777a.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
add a comment |
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
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 recommend0777a.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
add a comment |
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
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
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 recommend0777a.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
add a comment |
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 recommend0777a.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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 fileto transfer files between host and container, usingpushandpull.– code_dredd
Apr 13 '18 at 17:21