[lxc-users] proc-sys-fs-binfmt_misc.automount failed

[Fajar A. Nugraha]

On Sat, Sep 3, 2016 at 9:13 PM,  <webman at manfbraun.de> wrote:
> From your
> answer I assume, LXC itself does not need it.

Correct. Your container mounts it, and failed, but most program can
still run fine without it.

> If I install
> "autofs", the error dont go away.

Because autofs (most mount command, actually) doesn't work in lxc.

> I then just disabled and
> masked the service inside the VM - this helped.

Correct. That's a workaround.
On ubuntu lxd containter, there's  proc-sys-fs-binfmt_misc.mount
service, which works fine.

> if I need automount later at some point. BTW, my VMs are
> on ZFS anyways.

If you use lxd (not lxc) with zfs backend, you'd get some level of
storage management (including container disk quota) managed by lxd.
Container creation from a downloaded template will also be instaneous
(since lxd basically just need to run "zfs clone").

lxd can run fine without zfs (it can use btrfs or plain directory
storage backend), but the additional functionality is nice.

> I do not have the competition to decide about security, but
> experts told me, not to use Ubuntu, so I keep plain debian.

I'd say saying "x is more secure than y" without telling the whole
story (e.g. what you're using it for) can be misleading.

For example, from the host perspective (i.e. "can this application
that I run mess up the host"), running containers under ubuntu + lxd
(which uses unprivileged containers by default) is much more secure
than debian + lxc (which uses an old version of lxc, and privileged
containers by default).

> I try to avoid backports, because they caused me at least two
> nightmares in the last weeks ...

There are ways to run lxd (with unpriv) in debian. But since you have
nightmares even with backports, my best advice is to "if you know and
can accept the consequences, stick with what you're most familiar
with"

-- 
Fajar