You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 20, 2025. It is now read-only.
When using Windows Subsystem for Linux Version 2 on Windows there may be permissions error because of using the same volum on the host and in the container.
If files are owned by the host-user WordPress can't install/update/delete plugins/themes/media, when owned by the apache user (33) inside the container, the host-user can't edit the files.
I want to be able to edit theme and plugin files on my local host (IDE) and also allow WordPress to write files.
Until now I used a hacky bash-script to always overwrite the file permissions via chown and a sticky group bit, which didn't really work well.
Since this image (especially the docker-compose.development.yml) is only for local development permission escalation / security is not such a big risk. Therefore it would be easier to run the container and apache as the same user / group id as the local user.
/etc/passwd and /etc/group may need to be mounted as well (read only) to sync the user ids, depending on the host distro and the user/group id used (maybe user 1000:1000 already exists in the container?). If you encounter some file permissions about temporary files, this may be the reason.
When using Windows Subsystem for Linux Version 2 on Windows there may be permissions error because of using the same volum on the host and in the container.
If files are owned by the host-user WordPress can't install/update/delete plugins/themes/media, when owned by the apache user (33) inside the container, the host-user can't edit the files.
I want to be able to edit theme and plugin files on my local host (IDE) and also allow WordPress to write files.
Until now I used a hacky bash-script to always overwrite the file permissions via chown and a sticky group bit, which didn't really work well.
Since this image (especially the
docker-compose.development.yml
) is only for local development permission escalation / security is not such a big risk. Therefore it would be easier to run the container and apache as the same user / group id as the local user./etc/passwd
and/etc/group
may need to be mounted as well (read only) to sync the user ids, depending on the host distro and the user/group id used (maybe user 1000:1000 already exists in the container?). If you encounter some file permissions about temporary files, this may be the reason.References
The text was updated successfully, but these errors were encountered: