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 has been archived by the owner on Jul 11, 2022. It is now read-only.
I have largely ignored project config on a Craft CMS 3 project I work on due to it being a migration from Craft 2. I have now enabled it when we recently migrated it live and I'm finding Nitro under WSL has a bit of a constant fight with project config and the config/project path.
It seems I need to switch between chown (not chmod) between my WSL username which is jameswhite:jameswhite and 82:82 which I assume is the Docker container user in order to avoid permission denied or write errors when running project config commands or making requests to the control panel. This switch is needed when merging between branches i.e. develop and main which has changes within the config/project path, I have to switch the ownership with chown in order for git to be able to successfully run a git merge, otherwise I hit link errors/permission denied. When running project config commands I need to switch it to the Docker container user 82:82, otherwise this reports write/permission denied. This is becoming a bit tendinous and also makes me very concerned around write errors causing potential bad project config files.
Is there any better way of handling this? I already have to regularly run a recursive chmod 777 on the various paths outlined in the documentation, which while it is a local development environment files that are persistent such as composer.json are being committed into our source tree as 777. I'm aware this is more to do with how the WSL2 Docker implementation is but it is probably the one downside to using Nitro permissions constantly need to be managed or a script re-run that runs chmod a lot.
Has this got better Nitro 3 at all?
Edit: I don't intend for this to come across as a bit of rant. It is more of understanding if the permissions side with WSL2 in Nitro 3 has been modified to avoid constant chmod or chown usage.
The text was updated successfully, but these errors were encountered:
Description
I have largely ignored project config on a Craft CMS 3 project I work on due to it being a migration from Craft 2. I have now enabled it when we recently migrated it live and I'm finding Nitro under WSL has a bit of a constant fight with project config and the
config/project
path.It seems I need to switch between chown (not chmod) between my WSL username which is
jameswhite:jameswhite
and82:82
which I assume is the Docker container user in order to avoid permission denied or write errors when running project config commands or making requests to the control panel. This switch is needed when merging between branches i.e. develop and main which has changes within the config/project path, I have to switch the ownership with chown in order for git to be able to successfully run a git merge, otherwise I hit link errors/permission denied. When running project config commands I need to switch it to the Docker container user82:82
, otherwise this reports write/permission denied. This is becoming a bit tendinous and also makes me very concerned around write errors causing potential bad project config files.Is there any better way of handling this? I already have to regularly run a recursive chmod 777 on the various paths outlined in the documentation, which while it is a local development environment files that are persistent such as composer.json are being committed into our source tree as 777. I'm aware this is more to do with how the WSL2 Docker implementation is but it is probably the one downside to using Nitro permissions constantly need to be managed or a script re-run that runs chmod a lot.
Has this got better Nitro 3 at all?
Edit: I don't intend for this to come across as a bit of rant. It is more of understanding if the permissions side with WSL2 in Nitro 3 has been modified to avoid constant chmod or chown usage.
The text was updated successfully, but these errors were encountered: