wp-uploads and changing file permissions

[thedamon]

I am having an issue getting uploads to upload in my wp/docker environment.

I am getting the error The uploaded file could not be moved to wp-content/uploads. which I know is 'basic' file permissions stuff, but I haven't been able to resolve it. I know the web process needs to own the uploads folder and I'm wondering if it has to do with the fact that the server is running by apache.

So when I try echo(exec("whoami"));die(); in my php file I get www-data, but that user isn't on my system: when I go to the dir in my filesystem, the files are owned by me. This same setup is working on other Docker projects though.

Is the file ownership within apache (/var/www/html) different? how do I look at / alter those? When I open Docker CLI I don't see any difference

[thedamon]

I was able to look at the file ownership within apache by using
docker exec -t -i my_instance_name /bin/bash

I saw that all the files were owned be 1000, so using advice from this boot2docker issue I ran usermod -u 1000 www-data and restarted my container.

Seems to be working now!

It's a logical solution, but I'm curious if anyone knows if this is expected or normal behaviour for this container or why I ran into it here but other people on my team do not have the same problem

[yosifkit]

Anyone mounting a folder from OSX to their container in boot2docker will run into the same permission issues. Unless their process is running as root in the container, which is not the default within the "service" official images.

[thedamon]

I'm not fully aware of using boot2docker (just downloaded the mac toolbox about a week ago), but maybe that was baked in there. Just noticed the mac docker is out officially now so maybe that will generally get around that issue

[thedamon]

I've installed the official Docker for mac now and have lost the ability to upload files. Now all the files are set to root, but apache is operating as 'www-data' still. Is it prudent to change all the files to www-data?

What's the assumed permissions setup for this container using Docker for mac?

[willrstern]

I just ran into this today locally with Docker for mac because I'm using a volume for uploads. My fix was to use this Dockerfile for local development:

FROM wordpress:4.6

# entrypoint sleeps for 10sec before copying wordpress files...get rid of that
RUN sed -i 's/sleep 10/sleep 0/g' /entrypoint.sh
# add 'chown -R www-data: /var/www/html/wp-content/uploads' line to entrypoint
# to change /uploads permissions when container starts
RUN sed -i 's/set -e/set -e\nchown -R www-data: \/var\/www\/html\/wp-content\/uploads/g' /entrypoint.sh

COPY src /var/www/html

[tianon]

#249 is probably of use here.

In general, I'd recommend letting WordPress have write access to the /var/www/html directory so that it can properly perform auto-upgrade operations (as recommended by upstream), whether that means www-data or your own arbitrary user via #249.

In the future, these sorts of questions/requests would be more appropriately posted to the Docker Community Forums, the Docker Community Slack, or Stack Overflow.

[ejo]

In general, I'd recommend letting WordPress have write access to the /var/www/html directory

That's what anyone will do if the files in there (or even just in wp-content) are copied in. But if we wish to bind-mount /var/www/html to the host directory during development, /var/www/html in the container will be owned by root no matter what, and chown -R www-data:www-data /var/www/html inside the container has no effect for the same reasons. It looks like it is simply not possible to bind mount yet also allow non-root users (which the service in the container should run as!) to modify the data thus mounted. -- at least not in a general way that doesn't ruin portability across different host environments.

So it seems as though we are faced with a choice between having a nice efficient bind mount during development (yet being unable to do any operations such as updating plugins from the wp dashboard) or being fully able to operate the wp dashboard, but having to copy wp-content (at least) into and out of the container if we want a host dir to be in sync (e.g. for the purpose of having our wp-content under revision control).

[yosifkit]

@ejo, does #249 not work for you? You should be able to run the container as your user id and then you can have easy edit access via bind mount as well as wp dashboard updating. What are you running on (Docker for Mac, Boot2docker, Linux, etc)?

$ docker run -d --user "$(id -u)":"$(id -g)" -v /my/wp/path:/var/www/html wordpress

[ejo]

@yosifkit thank you for replying. I am using docker-compose on Docker for Windows. I was going to try the solution in #249 but I do not have /etc/password and /etc/group on my host OS so I cannot.

I am Linux fluent and prefer Linux for development work, but I was enthusiastically trying out the possibility of being able to do dev work in Docker-for-Windows while remaining booted into Windows (I am a frequent Adobe user and still need to run Photoshop and Lightroom on that platform for best efficiency). I ended up here talking about this specifically because I was tired of keeping my Linux dev work in a VM and having to deal with all the extra bulk and config of VMs, or alternatively dual-booting or in any way maintaining separate development machine vs. photography workstation.

The hope was that now that docker-for-windows has matured so far and docker-compose has come so far, and being especially excited about the excellence of the wordpress docker image so far and the ease of using docker-compose to add connected microservices in separate containers such as WP-CLI and phpmyadmin and logging containers, etc... anyway, my hope was that this would go smoothly in Windows! But the issue of Apache being unable to write to my bind-mount wp-content volume is shooting it all down so far. I really wanted to bind mount so that I could run phpstorm or other Jetbrains tooling as long as I've got this fast Windows box otherwise working well.

[yosifkit]

@ejo, oh, I see. I haven't used Docker for Windows much, but testing it real quick shows that yes from the container perspective, everything is mounted as root owned and anything created by any user is root owned and any user can modify files in the mount. From the windows perspective, all files I created from the container were owned by my user.

So, for me it just worked using Linux containers on Docker for Windows. First, turn on the drive sharing in Docker for Windows, in my case I shared `"C:".

# you would also want to define a volume for mysql, but this was just a demo
PS> docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=12345 mysql

# 172.17.0.2 is the IP of the mysql container (with a compose file you would just use the service name)
PS> docker run -d -v C:/Users/sauron/tmp/:/var/www/html -p 80:80 -e WORDPRESS_DB_HOST=172.17.0.2 -e WORDPRESS_DB_PASSWORD=12345 wordpress

# and then I had wordpress on `http://localhost`
# and all the file in my home dir could be changed by me

[ejo]

@yosifkit, I tried your example. Thank you for looking at this.

I have always had drive sharing turned on in Docker for Windows, for the drive on which I am doing all docker stuff and development work.

First I too care to remove all existing docker containers, volumes, and networks. Including any that were hidden/orphaned/"dangling". I ran docker system prune and also docker volume prune. I then used every command I know to make sure there were no other dangling/stranded/orphaned images, containers, volumes, or networks.

Your example resulted in the quick Wordpress install correctly, and I also shelled in with docker exec -it <auto generated name of container> /bin/bash and checked that some test files in the mount correctly arrived in the guest side of the volume. All good.

But Wordpress was unable to write to the directory of the mounted volume. Without changing anything at all, the first thing I did upon first login to the newly installed Wordpress was to ask it to update the 'Akismet' plugin. It requested FTP credentials. Inside the container, I think apache was running as www-data and the mounted volume's directory was owned by root. That is the same as what I'm seeing in my own docker-compose wordpress project.

If I just create a volume for the wordpress container and don't bind mount it, I can copy content into it from the host and apache/wordpress can write to the volume so everything works -- wp does not request ftp credentials when I try to update from the admin dashboard. But working that way blocks the goal of doing development work with a bind mount.

[ejo]

@yosifkit, I must apologize that I did not discover the following before my initial comment, but I did a lot of searching and thought I had covered the field at the time.

This does appear to be a long-standing Docker for Windows issue, and the following discussions can show that in only a brief reading:

https://github.com/docker/for-win/issues/497
https://github.com/docker/for-win/issues/39
https://github.com/wodby/docker4drupal/issues/29

The final link might seem the least relevant as it's from a docker-for-drupal group, but it directly involves the Docker For Windows problem and in fact contains the following quote, which if it's correct then I see I definitely have to just move all of my development back into Linux.

The problem was, every file written and folder created by a process in a Docker Container on Windows ends up being owned by root (inside Docker, physically owned by the user-credentials you set in the Docker settings), no matter which user runs the process. So after user www-data creates a folder, it does not have permission to write into the same folder anymore.

And I am very glad to just move back into Linux, it's only unfortunate that I will have to dual-boot or go in and out of VMs in order to still work with Photoshop and Lightroom, but that's just my problem.