The issue you were running into is with apparmor. 'dmesg'
would probably have shown you something like:
[ 4822.366235] type=1400 audit(1384973058.254:52): apparmor="DENIED" operation="mount"
info="failed type match" error=-13 parent=1272 profile="lxc-container-default"
name="/mnt/" pid=1273 comm="mount" fstype="ext4" srcname="/dev/loop0/" flags="ro"
You can allow your lxc container to do mounts of ext2, ext3, or ext4 filesystems in one of 2 ways. The simplist is to just add the following to the lxc config (/var/lib/lxc/$NAME/config
):
lxc.aa_profile = unconfined
lxc.cgroup.devices.allow = b 7:* rwm
lxc.cgroup.devices.allow = c 10:237 rwm
A much more restrictive solution that still grants the necessary permissions is to do the following:
$ sudo tee /etc/apparmor.d/lxc/lxc-custom-mounts <<EOF
# copied and modified from /etc/apparmor.d/lxc/lxc-default
profile lxc-container-extx-mounts flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/lxc/container-base>
mount fstype=ext4 -> /**,
mount fstype=ext3 -> /**,
mount fstype=ext2 -> /**,
}
EOF
# reload the lxc-containers profile
$ sudo apparmor_parser --replace /etc/apparmor.d/lxc-containers
$ sudo lxc-create -t ubuntu-cloud -n source-saucy-amd64 -- --release=saucy --arch=amd64
$ name="test1"
$ cfg=/var/lib/lxc/$name/config;
$ sudo lxc-clone -o source-saucy-amd64 -n "$name"
## modify the config to use the profile created above
$ sudo grep "#allow-loop" "$cfg" || sudo tee -a "$cfg" <<EOF
#allow-loop
lxc.aa_profile = lxc-container-extx-mounts
lxc.cgroup.devices.allow = b 7:* rwm
lxc.cgroup.devices.allow = c 10:237 rwm
EOF
You can then verify it works in the container with something as easy as:
$ truncate --size 100M my.img
$ mkfs.ext4 -F my.img
$ sudo mount -o loop,ro my.img /mnt
$ ls /mnt
lost+found
$ sudo umount /mnt
I've just opened bug 1257389 to address this. Hopefully sometime soon maas-import-ephemerals will work inside a container.
A bit late, but in case someone else is - like I was - searching for an answer to this "obvious" question:
The config file for a privileged container seems to be in /var/lib/lxc/${containerName}/config
.
Best Answer
The following answer repeats much of the information in the Links below
LXC
Containers are a lightweight virtualization technology. They are more akin to an enhanced chroot than to full virtualization like Qemu or VMware, both because they do not emulate hardware and because containers share the same operating system as the host. Therefore containers are better compared to Solaris zones or BSD jails. Linux-vserver and OpenVZ are two pre-existing, independently developed implementations of containers-like functionality for Linux. In fact, containers came about as a result of the work to upstream the vserver and OpenVZ functionality. Some vserver and OpenVZ functionality is still missing in containers, however containers can boot many Linux distributions and have the advantage that they can be used with an un-modified upstream kernel.
Making LXC easier
One of the main focus for 12.04 LTS was to make LXC dead easy to use, to achieve this, we’ve been working on a few different fronts fixing known bugs and improving LXC’s default configuration.
Creating a basic container and starting it on Ubuntu 12.04 LTS is now down to:
This will default to using the same version and architecture as your machine, additional option are obviously available (–help will list them). Login/Password are ubuntu/ubuntu.
Another thing we worked on to make LXC easier to work with is reducing the number of hacks required to turn a regular system into a container down to zero. Starting with 12.04, we don’t do any modification to a standard Ubuntu system to get it running in a container. It’s now even possible to take a raw VM image and have it boot in a container!
The ubuntu-cloud template also lets you get one of our EC2/cloud images and have it start as a container instead of a cloud instance:
And finally, if you want to test the new cool stuff, you can also use
[juju][3]
with LXCMaking LXC safer
Another main focus for LXC in Ubuntu 12.04 was to make it safe. John Johansen did an amazing work of extending apparmor to let us implement per-container apparmor profiles and prevent most known dangerous behaviours from happening in a container.
NOTE: Until we have user namespaces implemented in the kernel and used by the LXC we will NOT say that LXC is root safe, however the default apparmor profile as shipped in Ubuntu 12.04 LTS is blocking any armful action that we are aware of.
This mostly means that write access to /proc and /sys are heavily restricted, mounting filesystems is also restricted, only allowing known-safe filesystems to be mounted by default. Capabilities are also restricted in the default LXC profile to prevent a container from loading kernel modules or control apparmor.
More details on this are available here:
http://www.stgraber.org/2012/05/04/lxc-in-ubuntu-12-04-lts/
https://help.ubuntu.com/12.04/serverguide/lxc.html
http://www.stgraber.org/2012/03/04/booting-an-ubuntu-12-04-virtual-machine-in-an-lxc-container/