File permission issues in Ubuntu 20.04

[kevinquillen]

Fresh install of Ubuntu 20.04, relevant docker-compose section:

  php:
    image: wodby/php:$PHP_TAG
    container_name: "${PROJECT_NAME}_php"
    environment:
      PHP_SENDMAIL_PATH: /usr/sbin/sendmail -t -i -S mailhog:1025
      COLUMNS: 80 # Set 80 columns for docker exec -it.
    volumes:
      - ./:/var/www/html:cached

My host uid/gid are 1001:1001. Inside the container, wodby is 1000 (from /etc/passwd):

wodby@php.container:/var/www/html $ id
uid=1000(wodby) gid=1000(wodby) groups=82(www-data),1000(wodby)

When I run a docker-compose command, I receive various issues about unable to mkdir or read json files when using composer to install. One way around that is to amend all the docker-compose commands to have a --user=root passed, but this is not required to do on Mac or Windows within the same project.

Is there a way around this without having to build each image with a different uid/gid (node etc)?

[Dropa]

It is possible to change UID and GID for your current user but this is operation where you have potential to mess up your entire system.

However, you should try if simply changing the entire project group for www-data helps you. Run following in the project root;

sudo chgrp 82 -R .
sudo chmod g+w -R .

If you still get some issues while running e.g., drush commands, you may need to use (or change the UID/GID)

docker-compose exec -u www-data php drush cr

EDIT: or even simplier, switch the user on host. check sudo id 1000 to see which user was the first one.

[kevinquillen]

This was a temp environment, so creating a user and changing the ID to 1000 worked. Surely this is not the only way though? The reason this id was 1001 for me was that it was provisioned for me by IT (and the first account was their admin account). It is entirely possible in the future that users will run into this with uids not being 1000.

Although I am the only one running Linux locally now, so it probably won't be an issue - but I can see where others may run into this.

[Dropa]

Surely there are alternative solutions, but I guess each has own flaws.

For example, ignoring file permission changes for given repository (on the host that has permission issues)

git config core.fileMode false

could do the trick, as it would allow simply doing sudo chmod 777 -R ., but it would most likely end up in situation where intended file permission changes would not get pushed to the repository or new files would have wrong permissions.

I do not think docker(-compose) makes it possible to dynamically declare user, and since the user is created in the image build-phase possibilities most likely are either to rebuild the images, change IDs or try if group permission is enough.