How would you expect this to work here? The container can’t “see” the users from the host, so the user who owns that directory on the host does not exist as far as the container is concerned. Isn’t that what you signed up for using a user namespace? The namespaces are separate.
Presumably you turned on user namespaces because you don’t want containers to have full root privileges on the host filesystem. So why try to violate that separation of concerns by bind mounting in a directory from the host?
@nathanleclaire I do expect it to work, not only that, but I do expect that the userns ONLY usage pattern should be the OP usecase. For God’s sake!
The one and only usecase for userns is: “remap root inside container as regular user to avoid docker creating root-owned files locally” there is no other usecase.
And that usecase doesn’t really work.
Because bind mounts, that have all the correct permissions and uids are still not writable! How more badly designed that feature could be???
If host directory is owned by userns-mapped subuid/subgid, I do expect it to be writable.
What’s so surprising?
You have the same issue? The original post is 5 years old using a different storage driver. I don’t have problem with mounting using overlayfs2 and userns-remap
Could you share your case as well? Some commands and the output of your docker info. I will try to reproduce your issue because it really works for me the way I tried. I could use volumes created by docker volume create and mount non-existent folders created automatically on the host where I don’t have permission to create anything. I could mount my home directory as well so I couldn’t get any error message and I also could write the mounted filesystems.