Cannot deploy charm to new lxd container on machine: permissions error

[Katherine Cox-Buday]

Running on tip off commit 0806e96e6e79b530161cbb40f54bd8b338e0bad1

$juju boostrap bug lxd
$juju deploy ubuntu --to lxd

debug-log shows:

ERROR juju.provisioner provisioner_task.go:684 cannot start instance for machine "1/lxd/0": Failed to change ownership of: /var/lib/lxd/containers/juju-4e79aa-1-lxd-0/rootfs

[Richard Harding (rharding)]

I don't think this should work. When you bootstrap you're on the default model and can just deploy to fresh lxd instances with normal deploy. When you first land on the default model there is no machine to deploy to a nested lxd container on. You'd first have to get a machine and then --to 1/lxd/0 ?

What is the thought that --to lxd would do in this example case?

[Katherine Cox-Buday (cox-katherine-e)]

$juju help deploy

...
juju deploy mysql --to lxd (deploy to a new lxd container on a new machine)
...

The bug isn't that this isn't creating a new machine or anything, it's that it works as intended up to a point. It creates the machine, attempts to create the LXD container, and then it errors because of the error message.

I believe the bug is what's contained in the error message.

[Richard Harding (rharding)]

I see, ok thanks for the clarification.

[Katherine Cox-Buday (cox-katherine-e)]

Put more simply: I could reproduce this bug by doing the following:

$juju bootstrap
$juju add-machine
$juju deploy ubuntu --to lxd:1