It looks like you're sharing raw image files with multiple containers (mp0's vmid differs from that of the rootfs entry)? That'll most certainly result in unexpected breakage sooner or later. You should use a bind mounted directory instead, that should also get around the ordering issue...
That should do (unless for some reason your / is mounted with the `nodev` option).
You also have to adapt the `lxc.mount.entry` lines to bind this new file instead.
lxc.mount.entry = /devcontainer/net/tun dev/net/tun none bind,create=dir
The autodev hook isn't really usable with unprivileged containers. Neither the `modprobe` nor `mknod` will work.
The `lxc.mount.entry` line is correct, but you the permissions will have to be updated on the host side (since you're using device nodes from the host). So you either `chown` it to...
The nfs server is kernel-side, unprivileged containers won't have any more control over that than privileged containers. IMO it's generally not all that useful to move something which runs in the kernel anyway into a container. There's no option we provide which would "just enable" it. Better...
Lxc usually sends either a SIGPWR (30) or SIGRTMIN+3 (35), you could see if the container's init (pid 1) reacts to either of those.
It would be weird though if something from inside gentoo changed that behavior of the init system...
The kernel simply generally forbids using the mknod() system call required to create device nodes, no matter what permissions you otherwise have. If this changes in the future, those will definitely be on the whitelist. There are some mechanisms available already which could be used, such as an...
There have been some changes to the TFA handling and how the configuration is stored in the backend, but both old and new configurations should work with the new code.
Can you describe the login process you see on your UI?
-) Do you see the OTP input box below the password in the login window...
When you're in the container as root, you are using a user which has the `CAP_DAC_OVERRIDE` capability ("bypass file permission checks", see man 7 capabilities[1]) within its namespace. The directory `git_repositories` is owned by a user for which there exists a valid mapping inside the...
Update: That said, the change seems mostly about mount point cleanliness, so there's a chance it'll at least be temporarily reverted, as the issue description[1] doesn't seem to mention any actual breakage. (Otherwise it may become configurable. But my recommendation about moving to unprivileged...
Okay so with *privileged* 14.04 containers I can reproduce this. A bisect revealed an lxc commit which causes no functional change but simply removes an unnecessary mount entry which seems to confuse upstart in some way.
Considering the age and soon-to-be-EOL-ness of 14.04 I recommend moving...
Almost none of the installer ISOs come with graphics drivers. You need to add a serial socket, and connect to that via the xterm.js button.
After installation, when using 'virtio' graphics, you'll be able to see the machine via novnc as well.
The problem with mounting is that the kernel simply won't allow that regardless of any apparmor rules as most file systems (including nfs) simply aren't marked to be allowed in user namespaces. (The mount option checkboxes being enabled on the UI for unprivileged containers was an oversight...
This is just what happens when using reject rules currently. There is some basic ebtables support, but to fully support such a confguration we also need to add a way to a) use MAC filtering on input and/or b) add a way for users to configure ebtable rules (iow. the ability to add DROP rules for...
With privileged containers device usage is very restricted.
If you need a privileged container you'll need to allow the use of /dev/net/tun (the c:10:200 it's trying to allow access to, used for tunnel and tap device setup):
# /etc/pve/lxc/$vmid.conf
(...)
lxc.cgroup.devices.allow = c 10:200 rwm...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.