I'm trying to change the default permissions assigned to files when created by the docker daemon by changing the default umask. The docker daemon service runs as root and creates the files with umask of root. I tried changing the umask by adding a command to /etc/init.d/docker and also passed the desired umask(000) as an option to start-stop-daemon but none of them seem to be working. How can I change the default permissions assigned to files created by docker daemon?

Edit: I am trying to set the default permissions for files and folders created by the docker daemon on the host and not within a container. For instance, if a folder on host machine, mapped within a container, doesn't exist, docker automatically creates the folders and assigns permissions based on default umask(which is that of root).

  • Which files.created.by docker are you referring? Normally as a user launching containers, you don't deal directly with the files. Do you mean the images and files created within the overlay file system?
    – Otheus
    Commented Mar 9, 2016 at 11:56
  • @Otheus If I map a folder on host machine to a folder within the container and if that folder doesn't exist on host machine, Docker automatically creates the folder on host machine.
    – dnivra
    Commented Mar 10, 2016 at 3:38
  • So when you instantiate a container, sicker is creating folders on the host, and doing so without the permissions you need. Please update the question to clearly reflect this. I think I know what the problem is.
    – Otheus
    Commented Mar 10, 2016 at 7:52
  • @Otheus I thought it would be clear that I'm trying to influence permissions of the folders on host machine since I'm trying to change umask of the docker daemon which runs on host machine and not within a container.
    – dnivra
    Commented Mar 10, 2016 at 9:57
  • Because there are different use cases. Docker creates different files for different reasons. Which files impacts the answer. That is why I would like you to modify the question, because even after your edit, I cannot answer the question in general. But if your question regards ONLY the case in the previous comment, that has an answer
    – Otheus
    Commented Mar 10, 2016 at 11:11

1 Answer 1


Docker containers typically and by design run in unprivileged mode. When a process in its container runs as root, the process uid of 0 is mapped to the host OS as a different user (typically "nobody"). This, In order for any process within the container to read files from the host OS, those files must be world readable. Presumably, (caveat emptor since I'm not familiar with the code) Docker disregards the umask settings to ensure the directory it created via the -v option is actually readable by the container.

I'm not so sure about files created within the container via btrfs or overlayfs, whether these files, which are accessible by the host OS, must be publically readable. I'm also not sure if The creation of those files is handled within the container or on the Host OS.

  • Actually, the Docker daemon doesn't disregard the umask settings of the user it runs as(root) on host machine. The non-existent, shared folders created on the host machine have permissions assigned using the default umask for root. I'd like to override that and specify the folder to be world writeable so that the process inside the container can create files in the folder.
    – dnivra
    Commented Mar 12, 2016 at 5:39
  • If it honored umask, it would do that.
    – Otheus
    Commented Mar 12, 2016 at 8:39
  • Ah my bad - somehow I misunderstood you. I guess you were trying to say that Docker probably has an internal override of any umask settings passed to it.
    – dnivra
    Commented Mar 12, 2016 at 8:45
  • It's an educated evidence-based guess
    – Otheus
    Commented Mar 12, 2016 at 17:51
  • Keep in mind, docker is under rapid development and has a solid issue/feature request system in place at github.
    – Otheus
    Commented Mar 12, 2016 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .