ddev: Mutagen enabled: Drupal Package Manager hits exception when installing a module via the Project Browser

Expected Behavior

ddev macOS, Colima 0.5.4 + mutagen (Also Docker Desktop + mutagen, also Linux + mutagen)

i would expect that the install of a module runs through without any problem in the Project Browser UI

Actual Behavior

A few weeks or months back I was able to test the install process of new modules via project browser’s ui in drupal. everything worked as expected. when i started to test again a few weeks ago i ran all of a sudden into consistent errors. described here: https://www.drupal.org/project/automatic_updates/issues/3343793 and here https://www.drupal.org/project/automatic_updates/issues/3344542

for quite a while i had the suspicion the error was caused by the changes in package manager and the hardening that was done there. phenaproxima suspected in a comment in one of the issues it might be an issue on the ddev end. but then a few days ago @chrisfromredfin provided a drupalpod instance (gitpod + ddev) with a test environment for drupalcon that folks are able to test project browser there.

https://gitpod.io/#DP_PROJECT_NAME=project_browser,DP_ISSUE_FORK=,DP_ISSUE_BRANCH=,DP_PROJECT_TYPE=project_module,DP_MODULE_VERSION=1.0.x,DP_CORE_VERSION=10.0.x,DP_OLIVERO=1,DP_PATCH_FILE=,DP_REINSTALL=1,DP_INSTALL_PROFILE=standard/https://github.com/chrisfromredfin/DrupalPod

i was afraid that people might run into the same error i’Ve consistently expierenced. but surprisingly i was able to run an installation of a module without any exception and error. but since gitpod runs on linux mutagen was disabled.

i’ve then tried to set up a new site locally. this time i had mutagen disabled as well. there the install ran through without any problem as well. so i suspected the problem might be cause by mutagen. but i then activated mutagen for the gitpod instance. also with mutagen enabled a module install ran through flawless.

@rfay noted that sshfs (the mounttype i use) might cause surprising issues. i’ve now went ahead and set up a colima profile with 9p as the mounttype. but the same result as with sshfs. unable to install a module via the project browser ui with mutagen enabled

Steps To Reproduce

copy composer,json found at https://gist.github.com/rpkoller/3617dbb09995c24da02d6949e7147724 into an empty directory
ddev config --project-type=drupal10 --docroot=web --create-docroot --mutagen-enabled=true --php-version="8.2" --database=mariadb:"10.3"
ddev start
ddev composer install
ddev drush si -y standard --account-pass=admin
ddev drush en package_manager project_browser admin_toolbar admin_toolbar_tools admin_toolbar_links_access_filter
/admin/config/development/project_browser check the allow installing via the ui checkbox and save
go to /admin/modules/browse and click the add and install button on the metatag module card

Anything else?

ddev head version colima 0.5.4 qemu 8.0.0 limactl version 0.15.1

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (10 by maintainers)

Most upvoted comments

It turns out this is about the combined behavior of composer-stage and mutagen, but it’s not a bug related to DDEV. It’s something that’s will need to be worked on in Project Browser and such though. Closing.

rfay on Jun 10, 2023

It looks like we’re making progress in understanding this. The permissions are going to be the key.

It turns out that mutagen does not actually manage permissions, see

https://github.com/mutagen-io/mutagen/issues/282

So what is happening here that is fixed by ddev mutagen reset (which deletes the project_mutagen docker volume where all the code is) is

We have the funky perms described in https://github.com/php-tuf/composer-stager/issues/162 - Those are created on the project_mutagen docker volume as described
ddev mutagen reset actually destroys that volume (but it was all synced to the host)
ddev start syncs the code back to a new volume… but per https://github.com/mutagen-io/mutagen/issues/282 it uses default perms.
Now everything works

rfay on May 23, 2023

To narrow the root cause further down I’ve remembered that there was the option to use rsync as the file syncer when ted bowman mentioned it in the thread on the drupal slack. i’ve followed the steps setting up a new test instance except i’ve entered those two lines between step 6 and 7 :

ddev drush config:set package_manager.settings file_syncer rsync
ddev drush config:set package_manager.settings executables.rsync /usr/bin/rsync

with rsync active i was able to install pathauto , webform and metatag in a row and no error happened. so the root cause for the error is somewhere in the php file syncer?

rpkoller on May 22, 2023

It should respect it, as far as I know, because it’s using a SharedTempStore(Factory) from core…

chrisfromredfin on May 22, 2023