#DOCKER FOR MAC VOLUMES LOCATION DRIVER#

Since I think it's working as designed I'll close this ticket but if there's still a problem, let me know or create another ticket.Docker volumes are file systems mounted on Docker containers to preserve data generated by the running container. I think the main problem is that this feature is Mac only (so far). Looking at the 'handling permissions with docker volumes' link, this mechanism is intended to fix the 'permissions problem' that it describes.

explicitly shared with the container (via -v, filtered through the list of paths in the Whale menu -> Preferences -> File sharing).readable by the host user running Docker (Note Docker runs as a regular user on the Mac, not root).to guarantee that processes in the container can read any files which are both.to not require root on the host (therefore we can't create files owned by root).If this attempt fails, the object appears to be owned by the process accessing it until the extended attribute is readable again. If the user does not have permission to read extended attributes on an object (such as when that object’s permissions are 0000), osxfs attempts to add an access control list (ACL) entry that allows the user to read and write extended attributes. Ownership-based permissions are only enforced at the macOS file system level with all accessing processes behaving as the user running Docker. Subsequent requests for ownership metadata return the previously set values. When any containerized process changes the ownership of a shared file system object, such as by using the chown command, the new ownership information is persisted in the extended attribute of the object. Initially, any containerized process that requests ownership metadata of an object is told that its uid and gid own the object. The Ownership section of the file sharing documentation says that I believe this behaviour is expected on the Mac. If this is a bug it would actually solve a big problem like described here

#DOCKER FOR MAC VOLUMES LOCATION DRIVER#

Maybe I missed some big news, and would be glad if some one could point me to it.Ī linux colleague couldn't confirm, main diff we noticed was he was not using overlay2 but aufs as storage driver but as far as I understand storage driver is not used on volumes? (He just had time for a quick test, so no more info and I don't have access to a linux pc right now) Tested a debian based and others like php-cli too. It's not only for root, you can also use other users like games: docker run -itu games -rm -name mount-test -v '$PWD':/test -w /test alpine:latest /bin/ashĪnd it's also not for alpine images.

Run touch test2.txt, go back to the host system dir and see that test2.txt belong to the host user and group (and also test.txt).

Run ls -l or ls -ln in the container and see that test.txt belong to the current container user and not the host user.Then run docker run -it -rm -name mount-test -v '$PWD':/test -w /test alpine:latest /bin/ash.From a host dir of your choice run touch test.txt.Test with raw and qcow Steps to reproduce the behavior Tested on the different macs running above versions. same results) Informationĭocker version 18.02.0-ce-rc1, build 5e1d90a

(I also tested other user like www-data in the container. In Host: A file created in a dir which is mounted in a container will have 501:20 (or whatever your current host user and group id is) on the host and container Actual behaviorĪ file created in the container at the volume mount as root user has 0:0 in the container but 501:20 on the host systemĪ file created on the host at the location of the volume mount as current system user has 501:20 locally but 0:0 in the container In Container: A file created in a volume mount as root user will have 0:0 uid and guid on the host system and container

Docker for mac volumes location