Sorry to ask this here, but I cannot find a guide anywhere on the internet.
I realize that in the config, security.nesting must equal true and that there is no need to enable security.privilege? Are there any disadvantages for not allowing docker privileged access?
If someone can explain the small (hopefully!) steps required to enable docker inside a container, I would be most grateful 
Thank you!
I use unprivileged lxd container, i type this to change config to an existing container:
lxc config set container_name security.nesting true
Yes I am aware of this as I mentioned above, that security.nesting needs to be true. But that alone is not enough. Docker won’t run. Something else needs to be done for docker to run - I think.
What do you mean docker won’t run with that setting? 
Any error message that produce? much better you inform that error message if avalalbe. 
In my system is run normally, look at my SS below docker nginx container run in lxd container:
So then I must be doing something wrong. I will try again with a new freshly created container and let you know the error message (if any). Thanks for your help.
Oke siap. You’re welcome.
Afiadi, I created a fresh new container with just one change of security.nesting=true, and docker ran perfectly! So you were correct! So all is good 
but then I saw the video by Stephane Graber above…
In the video above, Stephane says to also set:-
security.syscalls.intercept.mknod=true
security.syscalls.intercept.setxattr=true
So I want to know if it works fine with just nesting enabled, are the above two changes necessary? If so, why?
Finally to make things even more confusing, Stephane says docker will not work if the storage pool is zfs. But mine is zfs and it works fine! Why? 
If anyone here (preferably Stephane himself) can clarify, it would be wonderful!
Thank you.
Docker can run in ZFS backed containers but will use the very slow and inefficient vfs backend rather than the much much faster overlay2 backend.
That’s why we usually recommend at least putting /var/lib/docker on a non-zfs pool.
The two security.syscalls.intercept are similarly related to the use of overlay2, so in your case you on ZFS with the slow vfs backend, you don’t need them, but when switching to overlay2, some layers will require them and would otherwise fail to unpack with odd errors.
(I’m no Docker expert, but it looks like the vfs backend simply takes every layers, stores them raw to disk and then for every single Docker container you create will read them back, compute the full layered filesystem and write it for that one container. So if you ever re-create your container or run more than one of them, you can expect a lot of CPU and disk usage that you wouldn’t have on overlay2.)
Thanks for the detailed explanation.
