Volume not writable to non-root user container


I have a Stack deployed to my swarm and I’m trying to create named local volumes managed by Docker to persist some things. I have two services, each has it’s own volume, however only one of them works - has read/write access to the volume. I noticed that the container that works runs as root and the other one runs as another user (uid:1000).

I am using a docker-compose.yaml file to configure like so:

  - my_volume:/some/directory/in/container:Z 

The container that DOES NOT have write permissions to the volume runs on CentOS and has user uid 1000. I have tried this with and without the :Z flag. My docker verison is 17.03.1-ce, build c6d412e.

Does anyone has any idea what I’m missing here? Is this supposed to work with non-root users as well?

Thank you.

So hopefully this isn’t too stupid a response.

  1. If you’ve already written to a filesystem as the root user, you won’t be able to write back any of the files you already wrote. Since Root (UID 0) != UID 1000, you’ll not have write access to the file by default.

  2. If “my_volume” is an NFS Mount some versions of NFS (v4 specifically but it depends how the export side of the NFS Mount exports the volume) change the root owner to “nobody” or “nfsnobody” which is a different UID than root also. Something to watch out for.

It would be helpful to know how “my_volume” is defined, it sounds potentially like a host mounted volume. Note that by default a local host mounted volume will not persist data on anything but the host it’s attached to. Since you’re talking about docker swarm deployment, if the container moves from one Docker Swarm host to another host the data is NOT going to follow it with a standard locally created volume…again, something to watch out for.

As to why you wouldn’t be able to write to the volume as a non-root user: If you are writing new files to a docker volume (not overwriting or re-writing/editing existing files) there should be no reason why you can’t write to them. I’d “docker exec” into your running container (the one running as UID1000) and see what happens when you try to “touch test” in the mount point for that volume.

Thanks for your reply Douglas.

Turns out I forgot to create the folder during image build time and therefore docker engine created it as root inside the container. Thanks to your “not too stupid a response” I was able to backtrack and realize my mistake.

Thanks again.

Kind regards.

1 Like

I spent two days to figure this out.
I had two container (one PHP:FPM app container and another Nginx web container. I was sharing volume from docker-compose.yml like below on the app container. And this does create the read/write problem for the web container as suddenly all the volumes shared from app containers appears to be owned by root because of following lines in the docker-compose.yml.

working_dir: /var/www
- ./:/var/www
- 9000

Then I simply removed these line and added volumes from the app.dockerfile for the PHP:FPM container server.
And now I can easily read and write and solved this issue.

It wasn’t totally clear to me exactly what you did to get this working. Would you mind share more details?

I think he is removed volume mapping


Then use named volume

            - php_vol: /path/to/folder