To provide some data from the host system to the container, I thought mount-bind will do the trick.
Specifically I may make a directory /data which is effectively located at:
# mount --bind /home/<username>/container-data/containername /var/lib/lxd/storage-pools/<poolname>/containers/<containername>/rootfs/data
It has the desired effect that I can conveniently add any data with my user and it would directly be available inside the container.
the container is unprivileged - thus not even the root inside the container may write to these files then
the container uses directory backend (otherwise not possible?)
Now the great question - Is this a good solution?
I am a bit insecure as it probably is a “avoiding to read the docs”-move.
I think it is not a solution how the system is supposed to be used and maybe some people with more in-depth knowledge of the system could know if there are any problems to be expected.
LXD provides this functionality as the built-in disk device type (see Instances | LXD).
Usage is like this:
lxc config device add <instance> <device name> disk source=/source/path/on/host path=/mount/path/inside/instance
This will have the same effect as above, bind mounting the source directory inside the instance, with the same UID/GID properties you saw in your own solution.
And you can also use the readonly=true and/or the shift=true properties to make the mount readonly and perform UID/GId shifting respectively.
Ah OK it was the words “supposed to be” which was implying that it wasn’t really a “solution”, but then the list of positives contradicted that