Actually this is a little more complicated, some better clarity would be required.
If we mount the host folder folder_a into guest folder folder_b and the folder_b was already created, "chown"-ed and "chmod"-ed when the container image was created (Dockerfile), then folder_b defined permissions must take precedence from the guest perspective. This is what is happening on my boxes. As the guest user is not supposed to exist in the host an answer like "add the permissions to the host" is not very beautiful, it would mean "give write permissions to everybody".
If folder_b was not already "prepared" for the mount upfront, but it is mounted "on the fly"; I have not found any way to change the permissions contextually. Trying to reason out loud: the docker daemon on the host does not know anything about the guest users. I am also curious if a chmod/chown on the fly with guest names is technically possible as an evolution of docker. My initial expectation is that the on the fly mount inherited the parent folder permissions ( if /mnt/a is owned by app_user, then mounting in /mnt/a/myMount would preserve app_user ownership to the child folder as well, however, the new mounted folder is owned by root in my tests )
From a security perspective, the guest operating the mounts should never mount its own secured/sensitive folders to the guests. It is generally assumed that if you give a volume to a guest, the guest must be able to execute any operation on it. However mounting "on the fly" produces a "root" owned folder inside the guest as root is the only user known to both guest and host.