DDEV install fails, because web folder is owned by root

[gitressa]

I am not sure when this started, I first noticed it a few days ago. Hoping it was an isolated event, which would go away next time, I just chowned web-folder to my user, and ran the command again. But it happened again ...

To reproduce, install Starshot in DDEV with the README method, and see that it fails, since web folder is not writable. Excerpts from the command line:

[...]
- Installing drupal/core (10.3.0-beta1): Extracting archive
  Install of drupal/core failed
[...]
Unhandled promise rejection with RuntimeException: /var/www/html/web/core does not exist and could not be created:  in phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:260

web folder is owned by root:

$ ls
total 560K
-rw-r--r--  1 user  user 6,8K 23 maj 11:53 composer.json
-rw-r--r--  1 user  user 510K 23 maj 11:54 composer.lock
drwxr-xr-x  2 user  user 4,0K 23 maj 11:53 drush
drwxr-xr-x  4 user  user 4,0K 23 maj 11:53 patches
-rw-r--r--  1 user  user 1,6K 23 maj 11:54 patches.lock.json
-rw-r--r--  1 user  user 2,9K 23 maj 11:53 phpunit.xml
-rw-r--r--  1 user  user 6,4K 23 maj 11:53 README.md
drwxr-xr-x 16 user  user 4,0K 23 maj 11:53 recipes
drwxr-xr-x  3 user  user 4,0K 23 maj 11:53 tests
drwxr-xr-x 12 user  user 4,0K 23 maj 11:54 vendor
drwxr-xr-x  2 root  root 4,0K 23 maj 11:54 web

[phenaproxima]

Fun times. Maybe something broke upstream in DDEV? What version are you on?

[gitressa]

$ ddev version
 ITEM             VALUE                                    
 DDEV version     v1.23.1                                  
 architecture     amd64                                    
 cgo_enabled      0                                        
 db               ddev/ddev-dbserver-mariadb-10.11:v1.23.1 
 ddev-ssh-agent   ddev/ddev-ssh-agent:v1.23.1              
 docker           26.1.3                                   
 docker-api       1.45                                     
 docker-compose   v2.27.0                                  
 docker-platform  linux-docker                             
 mutagen          0.17.2                                   
 os               linux                                    
 router           ddev/ddev-traefik-router:v1.23.1         
 web              ddev/ddev-webserver:v1.23.1              

Host machine is Debian 12. If I create a standard DDEV Drupal 10 instance, everything works as usual.

[isalmanhaider]

Try changing the ownership of the web folder to match the other folders. Ensure the web folder is owned by your user instead of root:

sudo chown -R user:user web
chmod -R 755 web

[gitressa]

Thanks for the suggestion, and that's also what I did as a workaround. But it shouldn't be necessary in the first place ... An observation: The web-folder is created by the ddev install command.

Also, if I ddev delete and then try to rm the folder, I get this message:

$  rm starshot/ -rf
rm: cannot remove 'starshot/web/sites/default/default.settings.php': Permission denied
rm: cannot remove 'starshot/web/sites/default/default.services.yml': Permission denied
rm: cannot remove 'starshot/web/sites/default/settings.php': Permission denied
rm: cannot remove 'starshot/web/sites/default/files': Permission denied

This also doesn't happen in standard DDEV/Drupal installations, so something is off with the permissions in Starshot ...

[phenaproxima]

I agree with @gitressa, it should not necessary to change the permissions yourself as a workaround.

If you look at .ddev/commands/host/install, though, it's doing all set-up in the context of the web container. The only command the host needs is open, which doesn't touch anything.

So I'm a bit stumped as to why this would be happening.

[gitressa]

Yea, it's strange. I wonder if the issue below and its PR are connected to this? It may have started since the release of DDEV 1.23.1 a week ago ...

• vscode - mkdir: cannot create directory ‘/workspaces/d9simple’: Permission denied ddev/ddev#6187
• build: fix devcontainers postCreateCommand permissions, fixes #6187 ddev/ddev#6194.

[roromedia]

It is strange on my side as well. I am on an Apple Silicon Mac and upgraded to the latest DDEV and installed Starshot without a problem. As soon as I launched it, it works, but soon after the database errors hit me like explained here: #59
I switched to "gRPC Fuse" as Randy Fay mentioned that VirtioFS might still be buggy. Then reinstalled Starshot and everything worked.
Afterwards I worked on other D10 projects and realized that I run into strange issues with the filesystem between host and guest system (saving on host does not update in Docker - when saved inside Docker it immediately responded on host IDE). I had to switch back to VirtioFS in order to proceed which makes now Starshot unreliable buggy again...
Tried a few other tweaks (like changing permissions, ...) and googled for solutions but haven't found any definitive solution to it yet.
My reasoning currently: It could maybe work with "gRPC Fuse" and enabled mutagen as I got the feeling that any file changes inside Docker always work in the direction to the host, but the other way round it doesn't - mutagen might eventually trigger the filesystem to sync more reliable? Not tested yet as I normally don't use mutagen because of the slight delays in sync.
Before Starshot I had zero issues with VirtioFS on DDEV 1.22.3 and DDEV 1.22.7 so I am not 100 % sure what combination of versions trigger the issues with VirtioFS - it is not Starshot itself. The only real difference between Starshot and my other projects I can see: Starshot is a single image in Docker Desktop and my other projects have a separate mariadb-image.
Maybe you could try to branch the Starshot database out into a separate image to see if the database corruption issue could be mitigated by that and then we could use VirtioFS which was at least for me flawless until now. I also got another D10 installation without DDEV spread over several Docker images (one for web, one for solr, one for db and so on), also there no VirtioFS-issues so far the last months.

[thegbomb]

I think it is an issue with the ddev start command. When no webroot exists, ddev start creates the folder.
It seems to be doing so with root ownership. Not sure if this is new or existed previously, though, as I usually composer create-project before doing ddev config and as such the webroot folder is usually already in place.

My workaround has been to edit the host > command > install file

Add a step to:
mkdir -p web
This creates the folder with the correct permissions before ddev does so.
composer install then populates it as expected.

[gitressa]

Thanks for sharing @roromedia and @thegbomb. My hunch is that "something" changed with DDEV 1.23.1 and instead of creating the web-folder as owned by the user, it is now owned by root. I reopened ddev/ddev#6158 with a link to this issue, and hope the DDEV team can take a look at it at some point.

In the meantime, as a workaround, Starshot could ship with an empty web-folder, so that it is owned by the user? Like so: https://github.com/phenaproxima/starshot-prototype/tree/main/web

[stasadev]

It is because of the change in .ddev/config.yaml made in:

• Install Project Browser with recipe support #74

working_dir:
  web: /var/www/html/web

web doesn't exist in this repo because of disable_settings_management: true.

And the working_dir is created by Docker itself, if it doesn't exist, we can't control this behavior:

• Set owner of items created by Docker on the host docker/cli#4582
• Add ability to mount volume as user other than root moby/moby#2259

---

I think you should commit the web directory by putting some file in it.

[phenaproxima]

I think that sounds like a good workaround. Let's create web/.gitkeep and commit that.

[thegbomb]

#95

[phenaproxima]

Merged #95, so tentatively closing this, but please reopen if the trouble persists.