ProcessWire: File permissions set to "600" instead of "644" when creating images or assets through a CMS (upload_dirs missing)

[StefanMedia]

Preliminary checklist

• I am using the latest stable version of DDEV (see upgrade guide)
• I have searched existing issues
• I have checked the troubleshooting guide
• I have run ddev debug test to include output below

Output of ddev debug test

Expand `ddev debug test` diagnostic information

======== Output file will be in /var/folders/bm/lng1_wv57ns3jwhpcf41_9380000gn/T/ddev-debug-test.txt ========


======== Existing project config ========
ddev installation alternate locations:
/usr/local/bin/ddev

These config files were loaded for project barmbek-nord: [/Users/smueller/Sites/barmbek-nord/.ddev/config.yaml]
name: barmbek-nord
type: php
php_version: 8.3
webserver_type: apache-fpm
webimage: ddev/ddev-webserver:v1.23.3
additional_hostnames: []
additional_fqdns: []
database: {mariadb 10.11}
performance_mode: none
bind_all_interfaces: true
host_webserver_port: 8081
project_tld: ddev.site
use_dns_when_possible: true
timezone: Europe/Berlin
composer_version: 2
nodejs_version: 20
default_container_timeout: 120


======== existing project customizations ========


======== installed DDEV add-ons ========
No registered add-ons were found. Add-ons installed before DDEV v1.22.0 will not be listed.
Update them with `ddev get` so they'll be shown.


======== mutagen situation ========
looking for #ddev-generated in mutagen.yml in project /Users/smueller/Sites/barmbek-nord
#ddev-generated
unmodified #ddev-generated found in .ddev/mutagen/mutagen.yml


======== Creating dummy project named tryddevproject-29952 in ../tryddevproject-29952 ========
Creating a new DDEV project config in the current directory (/Users/smueller/Sites/tryddevproject-29952)
Once completed, your configuration will be written to /Users/smueller/Sites/tryddevproject-29952/.ddev/config.yaml

Configuring a 'php' project named 'tryddevproject-29952' with docroot 'web' at '/Users/smueller/Sites/tryddevproject-29952/web'.
For full details use 'ddev describe'.
Configuration complete. You may now run 'ddev start'.


======== OS Information ========
Darwin Stefans-MBP 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79


======== User information ========
uid=501(smueller) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),702(com.apple.sharepoint.group.2),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)


======== DDEV version ========
 ITEM             VALUE                                    
 DDEV version     v1.23.3                                  
 architecture     amd64                                    
 cgo_enabled      0                                        
 db               ddev/ddev-dbserver-mariadb-10.11:v1.23.3 
 ddev-ssh-agent   ddev/ddev-ssh-agent:v1.23.3              
 docker           26.1.4                                   
 docker-api       1.45                                     
 docker-compose   v2.28.1                                  
 docker-platform  orbstack                                 
 global-ddev-dir  /Users/smueller/.ddev                    
 mutagen          0.17.2                                   
 os               darwin                                   
 router           ddev/ddev-traefik-router:v1.23.3         
 web              ddev/ddev-webserver:v1.23.3              



======== proxy settings ========

 HTTP_PROXY=''
 HTTPS_PROXY=''
 http_proxy=''
 NO_PROXY=''
 


======== DDEV global info ========
developer-mode=false
disable-http2=false
fail-on-hook-fail=false
instrumentation-opt-in=false
instrumentation-queue-size=0
instrumentation-reporting-interval=0s
instrumentation-user=
internet-detection-timeout-ms=3000
last-started-version=v1.23.3
letsencrypt-email=
mailpit-http-port=8025
mailpit-https-port=8026
mkcert-caroot=/Users/smueller/Library/Application Support/mkcert
no-bind-mounts=false
omit-containers=[]
performance-mode=none
project-tld=ddev.site
required-docker-compose-version=v2.28.1
router=traefik
router-bind-all-interfaces=false
router-http-port=80
router-https-port=443
simple-formatting=false
table-style=default
traefik-monitor-port=10999
use-docker-compose-from-path=false
use-hardened-images=false
use-letsencrypt=false
wsl2-no-windows-hosts-mgt=false
xdebug-ide-location=


======== DOCKER provider info ========
docker client location: lrwxr-xr-x  1 root  admin  53 Jul  6 10:33 /usr/local/bin/docker -> /Applications/OrbStack.app/Contents/MacOS/xbin/docker

docker client alternate locations:
/usr/local/bin/docker
/Users/smueller/.orbstack/bin/docker

Docker provider: 
docker version: 
Client:
 Version:           26.1.3
 API version:       1.45
 Go version:        go1.21.10
 Git commit:        b72abbb
 Built:             Thu May 16 08:30:38 2024
 OS/Arch:           darwin/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.4
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       de5c9cf
  Built:            Wed Jun  5 11:29:25 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.18
  GitCommit:        ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
 runc:
  Version:          1.1.13
  GitCommit:        58aa9203c123022138b22cf96540c284876a7910
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

DOCKER_DEFAULT_PLATFORM=notset

Expected Behavior

Newly uploaded images or assets through a CMS have the file permission set to "644".

Actual Behavior

I am using DDEV as a local development environment for the CMS ProcessWire.

When uploading images (for example) the file permissions are always set to "600". This results in an 403 error for each image resource after uploading those files via FTP to the remote server and viewing the website. The same behaviour occurs for assets like stylesheets or other image fies that are created by the CMS.

The correct permissions for those files should be set to "644" like it is set in my ProcessWire config.php:

$config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire

When I run the same web project in MAMP PRO instead of DDEV the file permissions are set correctly to 644. This is not a configuration problem of my CMS as it seems.

When I am disabling the Mutagen feature of DDEV the file permissions are set correctly to 644 as I would expect:

ddev mutagen reset && ddev config global --performance-mode=none && ddev config --performance-mode=none

Why is this the case?

Steps To Reproduce

No response

Anything else?

No response

[stasadev]

Hi @StefanThumann,

This is typical Mutagen behavior:

- mutagen-io/mutagen#23 (comment)

So if you want to preserve the permissions, don't use Mutagen.

after uploading those files via FTP to the remote server and viewing the website.
I am using DDEV as a local development environment for the CMS ProcessWire.

I don't understand, if you are using DDEV locally, why are you uploading files to a remote server from this local environment?

[StefanMedia]

Thank your for your response! I did not know that this is indeed the correct behaviour of mutagen. This topic can be closed.

[rfay]

I don't think that @stasadev 's answer is correct, and you have something going wrong.

Here's what I see when I create a file inside the container, in Mutagen's space:

$ ddev exec 'rm -f junk && touch junk && ls -l junk'
-rw-r--r-- 1 rfay dialout 0 Jul  8 12:55 junk

However, if you have upload_dirs configured correctly for your CMS, it should have files of the type you mention bind mounted, which is not involved with mutagen, but rather with Orbstack in your case. What is your upload_dirs set to?

Using Orbstack on mac (but arm64) I created a file using Drupal, where the upload_dirs is set to the correct directory (web/sites/default/files) and created an image. Inside the container I see:

rfay@d10-web:/var/www/html/web/sites/default/files$ find . -name "PXL*jpg" -ls
421254700   2352 -rw-rw-r--   1 rfay     dialout   2404671 Jul  8 12:56 ./2024-07/PXL_20240707_141455505.jpg

[rfay]

I see you have the project type set to php, so there's no default upload_dirs. You definitely will want to set that so that mutagen doesn't have the job of syncing your images and such. I think it reminds you of that on every ddev start, right?

I note that your config.php doesn't look like it's right? You say:

$config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire 

Shouldn't it be:

$config->chmodDir = '0755';
$config->chmodFile = '0644';

[rfay]

Oh and

This results in an 403 error for each image resource after uploading those files via FTP to the remote server and viewing the website. The same behaviour occurs for assets like stylesheets or other image fies that are created by the CMS.

Deployment of files is your job. You need to make sure that they get set correctly when you deploy them, both ownership and permissions. The permissions in your local environment (with any setup) is not something that you can count on when you deploy it. You absolutely must build a deployment script or technique that does the right thing when deploying.

(It's also unusual and normally dangerous to deploy CMS-created files to your production site. Normally you only want to go the other direction.)

[rfay]

I'd love to understand what's going on here. If you can't figure it out and sort out what's going on, please make an appointment with me at https://cal.com/randyfay/30min and we'll look through it. Regardless, you need a deployment technique, but I'd sure like to know what's happening to you.

[BernhardBaumrock]

@rfay you are absolutely correct!

I'm using DDEV for ProcessWire everyday and I got that "upload_dirs" warning on every project but it did not introduce any problems for me because I'm using github actions to deploy my websites.

It's easy to set this upload_dirs config though and I'll let PW folks know about it!

Here's a correct example config:

name: example.com
type: php
docroot: ""
php_version: "8.3"
webserver_type: apache-fpm
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
database:
  type: mariadb
  version: "10.6"
omit_containers: [dba]
use_dns_when_possible: true
timezone: Europe/Vienna
composer_version: "2"
web_environment:
  - TRACY_LOCALROOTPATH=$DDEV_APPROOT/


# this is the important part :)
upload_dirs:
  - site/assets/files

And the result after removing all files and then uploading a file via the CMS:

bernhard@main:/var/www/html/site/assets/files/1$ stat -c "%a %n" *
644 logo.0x260.jpg
644 logo.jpg

bernhard@main:/var/www/html/site/assets/files$ stat -c "%a %n" *
755 1

[StefanMedia]

I have reproduced what @BernhardBaumrock stated and can verify that the file permissions are now set correctly (644) even when mutagen is enabled, thus to the file path under upload_dirs.

[rfay]

When using upload_dirs you're not using mutagen for the upload_dirs. I still would love to know what was happening to you without this.

[rfay]

We would sure love to have a ProcessWire Quickstart in https://ddev.readthedocs.io/en/stable/users/quickstart/ - you can just click the edit button there or do a PR any way you like.

Closing this, but would love to work with you to discover why you were having the problem in the first place, as I couldn't reproduce the basic permissions problem, and would love to know more about it.

[BernhardBaumrock]

Hey @rfay finally I wanted to add ProcessWire to the list of CMSes but I found a problem. This is what I wanted to add:

mkdir my-pw-project && cd my-pw-project
curl -LJO https://github.com/processwire/processwire/archive/master.zip
unzip ./processwire-master.zip && rm -f processwire-master.zip && mv -f ./processwire-master/{.,}* . ; rm -rf processwire-master
ddev config --webserver-type=apache-fpm --upload-dirs='site/assets/files'
ddev start
ddev launch

The important part is the --upload-dirs='site/assets/files'

The problem with that line is that this creates the folder site/assets/files before PW is installed. This then breaks the PW installation procedure, which relies on the "site" folder naming convention.

PW has the concept of site-profiles. A site profile is basically a boilerplate setup for your project and it is typically shipped as a ZIP and when extracted it lies in the document root with a folder name like this:

site-foo
site-bar
site-baz

During installation PW grabs one of those folders based on the user input and then renames that folder to just "site"

So if a site folder exists, this tells the PW installer that we are at a later stage of the installation process. So with the DDEV setting for upload_dirs set to site/assets/files and having an existing "site" folder right from the beginning I can't install PW:

I'm in regular contact with the maintainer of ProcessWire so I'm quite sure we could add something to the installer to make it work, but I thought I'd ask you first what you think would be the best solution for this problem?

Thx in advance!