Issue
My main goal is to create a wordpress container on my linux machine for development on that container.
Therefore, I'm creating new volumes for the plugins and themes folders and even add read & write permissions, with the :rw option.
However, when I'm trying to create a new directory or file in those "volumes", I get an error message (especially in VS Code), that tells that I don't have the permission to add these volumes.
Moreover, the permissions based on the ll command shows that the owner is the only one with the w permissions. It means that I cannot use the group www-data and add it to my user in order to edit those volumes.
When I'm trying to run chmod 766 themes plugins, the volumes are not bind anymore, so this solution doesn't work.
I've searched the whole web (including stack overflow), but none of the answers didn't work for me, so I'm lost :(
Here are some details that can help you with finding solution, including the docker-compose.yml file.
Details
Error on VS Code when trying to add a directory named hello
A system error occurred (EACCES: permission denied, mkdir '~/Workspace/WordpressProject/themes/hello')
Run mkdir hello in terminal, returns this error
mkdir: cannot create directory ‘hello’: Permission denied
ll command result for volumes
drwxr-xr-x 2 www-data www-data 4096 Jun 14 23:54 plugins/
drwxr-xr-x 5 www-data www-data 4096 May 17 22:00 themes/
docker-compose.yml
version: '3'
services:
wordpress:
image: wordpress
links:
- mariadb:mysql
environment:
- WORDPRESS_DB_PASSWORD=${Database Name}
ports:
- "127.0.0.101:80:80"
hostname: ${Wordpress Host}
volumes:
- ./plugins:/var/www/html/wp-content/plugins:rw
- ./themes:/var/www/html/wp-content/themes:rw
restart: always
mariadb:
image: mariadb
environment:
- MYSQL_ROOT_PASSWORD=${Password}
- MYSQL_DATABASE=${Database Name}
volumes:
- ./database:/var/lib/mysql
restart: always
Versions
OS: Ubuntu 18.04 LTS
Docker: v18.05.0-ce, API v1.37
Editor (Visual Studio Code): v1.23.1
Please in VS terminal execute:
sudo chown -R $USER <directory_project>
Related
I'm on a Debian VPS on OVH cloud provider, running Docker.
Trying to make an apt update on the instance, I noticed that the disk of 40GB was full. What is quite surprising for an instance hosting 2 Wordpress blogs.
I tried to run:
sudo du -h /var/lib/docker/containers
One of the containers weight 27GB !
27G /var/lib/docker/containers/1618df0(...)d6cc61e
However when I run:
docker container ls --size
The same container only weight 500MB
1618df0(...) 782c(...) "docker-entrypoint.s…" 10 months ago Up 10 months 80/tcp blog_wordpress_1 2B (virtual 545MB)
The Docker Compose is pretty simple:
wordpress:
build:
# call the Dockerfile in ./wordpress
context: ./wordpress
restart: always
environment:
# Connect WordPress to the database
WORDPRESS_DB_HOST: db:xxxx
WORDPRESS_DB_USER: xxxx
WORDPRESS_DB_PASSWORD: xxxx
WORDPRESS_DB_NAME: xxxx
volumes:
# save the content of WordPress an enable local modifications
- ./wordpress/data:/var/www/html
networks:
- traefik
- backend
depends_on:
- db
- redis
The Dockerfile:
FROM wordpress
# printf statement mocks answering the prompts from the pecl install
RUN printf "\n \n" | pecl install redis && docker-php-ext-enable redis
RUN /etc/init.d/apache2 restart
Do you know what to investigate to understand this problem ?
Thanks
Ok, this was actually the logs... The logs are not counted by:
docker container ls --size
So I just truncated the logs, brutally:
sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"
This solve the problem for a while.
For the long term, I added these lines to the Wordpress container's Docker Compose, then deleted and recreated the containers:
logging:
options:
max-size: "10m"
max-file: "3"
I have installed Worpress in Rancher, (docker.io/bitnami/wordpress:5.3.2-debian-10-r43) I have to make wp-config writable but I get stuck, when get shell inside this pod to log as root :
kubectl exec -t -i --namespace=annuaire-p-brqcw annuaire-p-brqcw-wordpress-7ff856cd9f-l9gf7 bash
I cannot login to root, no password match with Bitnami Wordpress installation.
wordpress#annuaire-p-brqcw-wordpress-7ff856cd9f-l9gf7:/$ su root
Password:
su: Authentication failure
What is the default password, or how to change it ?
I really need your help!
The WordPress container has been migrated to a "non-root" user
approach. Previously the container ran as the root user and the Apache
daemon was started as the daemon user. From now on, both the container
and the Apache daemon run as user 1001. You can revert this behavior
by changing USER 1001 to USER root in the Dockerfile.
No writing permissions will be granted on wp-config.php by default.
This means that the only way to run it as root user is to create own Dockerfile and changing user to root.
However it's not recommended to run those containers are root for security reasons.
The simplest and most native Kubernetes way to change the file content on the Pod's container file system is to create a ConfigMap object from file using the following command:
$ kubectl create configmap myconfigmap --from-file=foo.txt
$ cat foo.txt
foo test
(Check the ConfigMaps documentation for details how to update them.)
then mount the ConfigMap to your container to replace existing file as follows:
(example requires some adjustments to work with Wordpress image):
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: nginx
volumeMounts:
- name: volname1
mountPath: "/etc/wpconfig.conf"
readOnly: true
subPath: foo.txt
volumes:
- name: volname1
configMap:
name: myconfigmap
In the above example, the file in the ConfigMap data: section replaces original /etc/wpconfig.conf file (or creates if the file doesn't exist) in the running container without necessity to build a new container.
$ kubectl exec -ti mypod -- bash
root#mypod:/# ls -lah /etc/wpconfig.conf
-rw-r--r-- 1 root root 9 Jun 4 16:31 /etc/wpconfig.conf
root#mypod:/# cat /etc/wpconfig.conf
foo test
Note, that the file permissions is 644 which is enough to be readable by non-root user.
BTW, Bitnami Helm chart also uses this approach, but it relies on the existing configMap in your cluster for adding custom .htaccess and persistentVolumeClaim for mounting Wordpress data folder.
Intro:
I am trying to run a few WP-CLI commands for maintenance as a part of my release process on my production sites. I can execute the following commands against the docker-compose file below successfully.
docker-compose run wp-cli_collinmbarrett-com core update
docker-compose run wp-cli_collinmbarrett-com plugin update --all
docker-compose run wp-cli_collinmbarrett-com theme update --all
docker-compose run wp-cli_collinmbarrett-com db optimize
I have a plugin (WP-Sweep) installed on the site that adds its own WP-CLI command. When I try to run this command, it fails.
docker-compose run wp-cli_collinmbarrett-com sweep --all
/usr/local/bin/docker-entrypoint.sh: exec: line 15: sweep: not found
In a non-dockerized setup, I have verified that the WP-Sweep command for WP-CLI works successfully.
Question:
How can I run plugin-installed WP-CLI commands when running in a containerized environment with Docker Compose? Do I need to somehow make the WP-CLI container aware of the installed plugins other than having a shared volume?
My docker-compose.yml:
version: "3.7"
services:
wp_collinmbarrett-com:
image: wordpress:fpm-alpine
restart: always
networks:
- reverse-proxy
- collinmbarrett-com
depends_on:
- mariadb_collinmbarrett-com
volumes:
- collinmbarrett-com_files:/var/www/html
mariadb_collinmbarrett-com:
image: mariadb:latest
restart: always
networks:
- collinmbarrett-com
volumes:
- collinmbarrett-com_data:/var/lib/mysql
wp-cli_collinmbarrett-com:
image: wordpress:cli
networks:
- collinmbarrett-com
volumes:
- collinmbarrett-com_files:/var/www/html
networks:
reverse-proxy:
external:
name: wp-host_reverse-proxy
collinmbarrett-com:
volumes:
collinmbarrett-com_files:
collinmbarrett-com_data:
Full config on GitHub.
Not answering directly to your command needs (I didn't tried yet), but I wanted to share with you all the configurations I'm using in hope it helps you.
My docker-compose.yml has:
services:
...
# Mysql container
db:
...
# Wordpress container
wp:
...
wpcli:
image: wordpress:cli
user: "33:33"
volumes:
# necessary to write to the filesys
- ./php-config/phar.ini:/usr/local/etc/php/conf.d/phar.ini
- wp_app:/var/www/html
- /tmp/wp-temp:/tmp/wp-temp
environment:
HOME: /tmp/wp-temp
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: $WORDPRESS_DB_USER
WORDPRESS_DB_PASSWORD: $WORDPRESS_DB_PASSWORD
WORDPRESS_DB_NAME: $WORDPRESS_DB_NAME
depends_on:
- db
- wp
volumes:
wp_app: {}
...
Please note that as mentioned on Running as an arbitrary user section in https://hub.docker.com/_/wordpress:
When running WP-CLI via the cli variants of this image, it is
important to note that they're based on Alpine, and have a default
USER of Alpine's www-data, whose UID is 82 (compared to the
Debian-based WordPress variants whose default effective UID is 33), so
when running wordpress:cli against an existing Debian-based WordPress
install, something like --user 33:33 is likely going to be necessary
(possibly also something like -e HOME=/tmp depending on the wp command
invoked and whether it tries to use ~/.wp-cli)
You will need to define WP-CLI user as www-data with user id and group id = 33. This is why I defined user: "33:33". Also, the command might need to download temporary content, so I defined a HOME environment setting. Please also note that HOME mapped in your Host should also be assigned with user 33:33 ownership ids, otherwise WP CLI can't write to the filesys.
Also, PHP.ini in the WPCLI image has the setting phar.readonly as On, so you need to override it. I've add a specific ./php-config/phar.ini file that has that override:
phar.readonly = Off
To execute a plugin installation I do, on my docker-compose.yml folder, the following command:
docker-compose run --rm wpcli plugin install wp-mail-smtp --force --allow-root
Please note that --force --allow-root are optional.
In my first attempt at running a more complex application through Docker, I selected the Symfony Demo app and assembled a docker build structure to accommodate it.
The first image is httpd: it runs as root (dropping to www-data afterwards) and talks through the 'server' custom network.
The second image is php (fpm): it runs as root (dropping to www-data afterwards) and also talks through the 'server' custom network.
The third image is composer: it runs as UID and GID 1000. Its entrypoint command is composer create-project symfony/symfony-demo symfony-demo
All containers share the same bind mount, where the symfony-demo app is located.
Then I go to localhost:8080 in the browser just to end up with a Symfony error:
The stream or file "/usr/local/apache2/htdocs/symfony-demo/var/log/dev.log" could not be opened: failed to open stream: Permission denied
The thing is... this file mentioned doesn't even exist at /var/log/. That folder is empty.
All files in the bind mount have permissions 1000:1000 (my user UID/GID) and are configured like this: -rw-r--r--.
I've tried running httpd and php as: UID 33 (www-data) and GID 33; UID 0 (root) and GID 33 (and vice-versa); and also as 1000:1000 or 1000:33, but all these combinations (when they successfully get httpd/php to start up) result in the same error.
docker-compose.yml:
version: "3"
services:
httpd:
build: "./httpd/"
container_name: "webserver"
depends_on:
- php
ports:
- "8080:80"
networks:
- server
volumes:
- ../app:/usr/local/apache2/htdocs/
php:
build: "./php/"
depends_on:
- composer
container_name: "php"
networks:
- server
volumes:
- ../app:/usr/local/apache2/htdocs/
composer:
build: "./composer/"
container_name: "composer"
user: "1000:1000"
volumes:
- ../app:/usr/local/apache2/htdocs/
networks:
server:
driver: bridge
composer Dockerfile:
FROM composer:1.8
WORKDIR /usr/local/apache2/htdocs/
CMD ["composer", "create-project", "symfony/symfony-demo", "symfony-demo"]
httpd Dockerfile:
FROM httpd:2.4
COPY ./config/httpd.conf /usr/local/apache2/conf/httpd.conf
COPY ./config/httpd-vhosts.conf /usr/local/apache2/conf/extra/httpd-vhosts.conf
COPY ./config/php-fpm.conf /usr/local/apache2/conf/extra/php-fpm.conf
WORKDIR /usr/local/apache2/htdocs
php Dockerfile:
FROM php:7.3-fpm
RUN cp "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
COPY ./config/timezone.ini $PHP_INI_DIR/conf.d/
COPY ./config/www.conf /usr/local/etc/php-fpm.d/www.conf
RUN apt-get update && \
apt-get install -y libicu-dev
RUN docker-php-ext-install intl
WORKDIR /usr/local/apache2/htdocs
just give the write permission
chmod -R 777 /usr/local/apache2/htdocs/symfony-demo/var/log/dev.log
here symfony doc for file permission: https://symfony.com/doc/current/setup/file_permissions.html
On second thoughts: my previous solution (as is) doesn't work in RHEL/Fedora/CentOS, because www-data does not exist there by default, causing Docker to fail to start.
My new solution - distro agnostic
For simplicity, I've decided to simply write composer's entrypoint script to set -rw-rw---- permissions at /app. That way, I can run composer as user 1000 and the same group PHP runs as (a new user and group was created just for that). Now PHP can write to SQLite3 database files inside the project and composer writes as user 1000, which I can edit.
It's basically what #habibun said, but I only need to give group write permissions, not full write permissions.
Be aware that SELinux will deny composer write access to your bind mount. You must configure SELinux to allow this operation.
This is my repository where this project is stored, if you're looking for a reference: https://github.com/o-alquimista/symfony-demo-docker/
User namespace solution - works fine for Debian/Ubuntu hosts
Composer should write to /app as user 33 (www-data), and so should php and httpd after they drop privileges. I was able to keep present permission settings (only owner can write) by making use of user namespaces. The user www-data is now mapped to the range 967 and beyond, which will result in user 33 being = me (user 1000).
Now all containers can write where they need to, and I can edit the project files as an unprivileged user.
Error:
The uploaded file could not be moved to wp-content/uploads/.../....
Environment:
Wordpress Docker image is created from a base Wordpress image then the files are mapped in and out, for development:
version: '3'
services:
wordpress:
restart: always
environment:
WORDPRESS_DB_NAME: ...
WORDPRESS_DB_HOST: ...
WORDPRESS_DB_USER: ...
WORDPRESS_DB_PASSWORD: ...
image: wordpress:latest
ports:
- 38991:80
volumes:
- ./:/var/www/html
We talk to a dev database hosted external to the Docker container.
Image is built - and sent up to the server. Then, CMS user attempts to upload an image and the Wordpress build moans that the uploaded file could not be moved to wp-content/uploads/.../.... We don't get this error on localhost.
Could some devops experts kindly point us in the right direction on what needs to be done for this to tally up on the server.
The permissions are incorrect on the wp-content/uploads directory. I had the same error and in my case the upload folder's permissions and user/group where set wrong and also some folders inside were set to root. But that's probably because I imported a backup.
To fix the upload you can add the following two commands to your deploy pipeline/script or use docker exec -it <container-name> bash to perform it manually on the container.
Set the correct user/group on the uploads folder: $ chown -R www-data:www-data uploads/*
Set the correct permissions: $ chmod 755 uploads/*