Permission Issues
SysEngDan opened this issue · comments
I'm having nothing but difficulty getting the site to (1) render properly and (2) save files properly.
Question 1: What is the correct user/UID & group/GID which the files should be owned on the local file system (meaning outside of any container, located on the docker host)?
Question 2: What should be the file and folder permissions which the files should be set on the local file system?
My experience has been that I have to chmod all files to 777 for the site to render (Wordpress website). Then I installed a backup plugin, created a backup, and upon downloading the static file, I get a "Permission Denied".
Docker 19.03.12
CentOS 7.6
Nginx: nginx:1.19.1
PHP-FPM: bitnami:7.4.9-prod
Source files: /san/data1/services/mywebsite.com/root/html
Deploy step: docker stack deploy mywebsite_com -c /san/data1/services/mywebsite.com/docker-compose.yml
PHP-FPM Docker Compose
version: '3'
services:
php:
image: bitnami/php-fpm:7.4.9-prod
volumes:
- /san/data1/services/mywebsite.com/root/html:/app
extra_hosts:
- "mywebsite.com:192.168.30.50"
- "www.mywebsite.com:192.168.30.50"
networks:
- webproxy-overlay
deploy:
replicas: 1
resources:
limits:
cpus: '1'
memory: 2048M
networks:
webproxy-overlay:
external: true
Nginx Docker Compose
version: '3.5'
services:
frontend:
image: nginx:1.19.1
volumes:
- /var/log/docker-nginx:/var/log/nginx
- ./nginx:/etc/nginx
- /san:/san
ports:
- "80:80"
- "443:443"
- "5020:5020"
networks:
- webproxy-overlay
deploy:
restart_policy:
condition: any
replicas: 1
networks:
webproxy-overlay:
external: true
Nginx Config for mywebsite.com
server {
listen 80;
server_name mywebsite.com www.mywebsite.com;
location ^~ /.well-known/acme-challenge/ {
allow all;
default_type "text/plain";
root /etc/nginx/certs/letsencrypt/temp_auth;
}
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
server_name mywebsite.com www.mywebsite.com;
ssl_certificate /etc/nginx/certs/letsencrypt/live/mywebsite.com/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/letsencrypt/live/mywebsite.com/privkey.pem;
add_header Strict-Transport-Security "max-age=31536000";
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
root /san/data1/services/mywebsite.com/root/html;
location / {
real_ip_header proxy_protocol;
set_real_ip_from 192.168.30.1/32;
try_files $uri $uri/index.php;
}
location ~ \.php$ {
resolver 127.0.0.11 valid=10s;
real_ip_header proxy_protocol;
set_real_ip_from 192.168.30.1/32;
set $upstream mywebsite_com_php;
fastcgi_pass $upstream:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /app$fastcgi_script_name;
}
}
Hi, the bitnami/php-fpm is a root image so the service is executed as the root user, so there shouldn't be any issue related to permission if the files permission are configured properly for root.
On the other hand, can you provide some examples of the error trace? Is the issue related to PHP or Nginx? Here you can find an example about how to deploy a PHP application using bitnami/php-fpm and bitnami/nginx containers.
By last, we also have a Docker image and docker-compose for the WordPress+Nginx solution, you can take a look in the GH repository: https://github.com/bitnami/bitnami-docker-wordpress-nginx
Thank you, @carrodher . I was able to get the site to render after deleting one problematic directory. Here's what I do:
cd /san/data1/services/mywebsite.com/root/html/
sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 755 {} +
chown -R root:root *
chown -R root:root .
Then, the site will render.
Next, I go to upload a new plugin through the Wordpress UI and I'm presented with a Wordpress error that the folder wp-content/uploads/2020/08 is not writable.
Any advice? I tried setting the directory to 775, then 777. Once set to 777, the plugin upload worked but Wordpress returned the page where it asked for FTP credentials to move the plugin.
I am glad you were able to fix the first issue, regarding the new error, I think you should check the user running WordPress and configure the permission according to that user. I am not an expert in deploy WordPress from scratch, but you can take a look at WordPress with NGINX Docker image plus docker-compose provided by bitnami in this repository https://github.com/bitnami/bitnami-docker-wordpress-nginx, maybe you can find some ideas about how it's configured and translate the configuration to your environment.
I am glad you were able to fix the first issue, regarding the new error, I think you should check the user running WordPress and configure the permission according to that user. I am not an expert in deploy WordPress from scratch, but you can take a look at WordPress with NGINX Docker image plus docker-compose provided by bitnami in this repository https://github.com/bitnami/bitnami-docker-wordpress-nginx, maybe you can find some ideas about how it's configured and translate the configuration to your environment.
Wordpress is not a process that runs with a user, it is a set of PHP scripts, so it runs as whatever user is running PHP-FPM, however, when I run the php-fpm container from bitnami and together with the nginx contianer, there is an issue with permissions. The two users are not lining up, only chmoding everything to 777 works, and that shouldn't be the solution. There is clearly an issue with users and groups. I hope someone who authors the bitnami plugin can speak up.
Hi @SysEngDan, by checking the UID of the processes involved in serving the application you can see that the user processing the requests is daemon. daemon has UID 1, you can check that in /etc/passwd.
$ ps auxf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 202536 27012 ? Ss 14:23 0:00 php-fpm: master process (/opt/bitnami/php/etc/php-fpm.conf)
daemon 270 0.5 0.0 202600 16776 ? S 14:35 0:00 php-fpm: pool www
$ grep daemon /etc/passwd
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
The wp-content directory should be writable by the daemon user, so you may need to change the ownership settings of that directory:
find wp-content -type d -exec chmod 775 {} +
chown -R :1 wp-content
Then, if you exec into the container, the directory should be owed by root with group daemon, and it will be writable because the permissions are 775.
Please, make sure you do a backup of your files in case something goes wrong in the process.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.