Unable to start containers after upgrade to 1.0.7-0ubuntu0.5 on trusty

Thanks for reporting this bug.

As a workaround, please update the entry to read:

lxc.mount.entry=/media/array/backup/blixten var/backup none bind 0 0

Hi Tobias - Can you share what Ubuntu release you're using?

The bug report title makes it pretty clear that this is the security fix on trusty.

This bug was fixed in the package lxc - 1.0.7-0ubuntu0.6

---------------
lxc (1.0.7-0ubuntu0.6) trusty-security; urgency=medium

  * Fix breakage of some configurations where // ends up in the mount
    target. (LP: #1501310) (LP: #1476662)

 -- Serge Hallyn <email address hidden> Wed, 30 Sep 2015 10:38:14 -0500

/home/ubuntu/nzos/volumes/1.0.0/common/shared /var/lib/lxc/0002/rootfs/nzos/./__shared__ none ro,bind 0 0

This line is giving the same error. With 1.0.7-0ubuntu0.6 installed.

lxc-start: utils.c: ensure_not_symlink: 1398 Mount onto /usr/lib/x86_64-linux-gnu/lxc//nzos/./__shared__ resulted in /usr/lib/x86_64-linux-gnu/lxc/nzos/__shared__

lxc-start: utils.c: safe_mount: 1423 Mount of '/home/ubuntu/nzos/volumes/1.0.0/common/shared' onto '/usr/lib/x86_64-linux-gnu/lxc//nzos/./__shared__' was onto a symlink!
lxc-start: conf.c: mount_entry: 2051 No such file or directory - failed to mount '/home/ubuntu/nzos/volumes/1.0.0/common/shared' on '/usr/lib/x86_64-linux-gnu/lxc//nzos/./__shared__'
lxc-start: conf.c: lxc_setup: 4160 failed to setup the mounts for '0002'
lxc-start: start.c: do_start: 688 failed to setup the container
lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2
lxc-start: start.c: __lxc_start: 1080 failed to spawn '0002'
lxc-start: lxc_start.c: main: 342 The container failed to start.
lxc-start: lxc_start.c: main: 346 Additional information can be obtained by setting the --logfile and --logpriority options.

In reference to above comment - should I open a new bug?

I opened 1501491

Quoting Stephen (<email address hidden>):
> /home/ubuntu/nzos/volumes/1.0.0/common/shared
> /var/lib/lxc/0002/rootfs/nzos/./__shared__ none ro,bind 0 0

Plesae get rid of the "./" in the path.

We could check for this in the paths, but I start to become
concerned at that point that we're begging for parsing errors
to allow new security bugs to come through.

I cannot simply remove those characters as this is fstab generated by our deployment S/W. I would think that a patch (assuming last digit in a version is a patch level) should not break existing code.

Thanks,

it works just fine with the new 1.0.7-0ubuntu0.6

Best regards
Tobias