Home directory has wrong ownership if created by lxd in arranging a mount first

I've just been able to reproduce this by following these steps:

```
$ lxc init ubuntu:x c1
$ lxc config set c1 raw.idmap "both 1000 1000"
$ lxc config device add c1 foo disk path=/home/ubuntu/foo source=/home/daniel/jjl
$ lxc start c1
$ lxc exec c1 -- ls -lah /home/ubuntu
total 16K
drwxr-xr-x 4 root root 4.0K Feb 19 12:46 .
drwxr-xr-x 3 root root 4.0K Feb 19 12:46 ..
drwx------ 2 ubuntu ubuntu 4.0K Feb 19 12:46 .ssh
drwxr-xr-x 6 ubuntu ubuntu 4.0K Oct 23 2017 foo
```

Creation of the directory is performed by lxd before boot and therefore before cloud-init runs. When cloud-init calls useradd, useradd sees that the directory already exists and therefore doesn't do anything with it (as it treats it as an existing home directory). This means that (a) the user doesn't own the home directory (it is owned by root, the only user in the container when the directory was created), and (b) the contents of the skeleton directory don't get copied over to home directory (because useradd, sensibly, doesn't want to overwrite any existing files). As such, the workaround above is incomplete, because the skeleton directory isn't copied over.

We've just spent some time discussing this at the sprint, and there isn't a clear, quick solution; cloud-init doesn't know that this home directory isn't _meant_ to already exist, and lxd doesn't know that it's bind-mounting somewhere that's going to be a home directory once boot is complete. We discussed that an alternate workaround would be to bind-mount in to a non-home location and then re-bind (using cloud-config) in a runcmd to the eventual destination. A more complete solution might involve a lxd cloud-init data source, or lxd generating cloud-config to perform the aforementioned new workaround transparently.

(I've added lxd to the bug, as it's also a component in the issue.)

Yeah, not much LXD can do about this unfortunately. We do create any missing intermediate directories as can be seen in this case, but there's no good way to know what the owner of every one of those intermediate directories should be, nor would it help here as skel still wouldn't get applied.

You pretty much have two options:
 1) Only add the device after the container initial's start
 2) Bind-mount this stuff somewhere other than the user's home directory

In the second case, I guess you could have a cloud-init snippet which then sets up a systemd unit to bind-mount that inside the container from /srv/whatever to /home/ubuntu/foo.