keebeegee
commented
2 years ago Permission issue most likely caused by ignoring "newgrp docker"
Open keebeegee opened 2 years ago
keebeegee
commented
2 years ago Permission issue most likely caused by ignoring "newgrp docker"
orangewolf
commented
2 years ago thank you for your report =-)
I think there are fundamentally two issues here. The first one is that we need add a migration to the schema.rb file and commit that in main. When you start up fresh it should load the schema and not need a migration right off the bat, but if one is not checked in then db/schema.rb file will be modified.
Second, and I think this is the bigger issue in regards to running in your original configuration is that inside the container, the db/schema.rb file can not be written too. This means that the docker-compose file mount is not getting the correct permissions. In both MacOS and Windows, bind mounts are handled by a fairly complex mount/sync process. My understanding is that in native Linux this process is simpler. I'm wondering, if you were to run docker-compose run initialize_app sh and look inside the container, are all the file permissions incorrect? Does your code checkout outside the container have the same user / permissions as the files inside it?
I do not have a lot of experience running docker-compose with bind mounts on Linux hosts (we mostly use Linux hosts for deployments and bind mounts are not common there). The first issue is one I'll take care of, but the if you can provide more information about the second it sounds like we at least need to add an optional step to the README.
keebeegee
commented
2 years ago Dear @orangewolf thanks for your input. I am re-opening this issue again as a proper start was only achieved once out of ~30 times. All subsequent tries after the single successful one failed as described above. Removing all images and re-creating them would not change anything.
Just to be clear: The err as described above occurred on a Ubuntu 20.04 LTS. I later tried to run the stack on a WIN WSL 2 (Ubuntu 20.04 LTS) and all containers started properly.
Will look into your advise - thanks again for looking into this.
adamhgriffith-uofu
commented
1 year ago Hi @keebeegee and @orangewolf ,
On Linux hosts, the file permissions set on content in the Docker volume are identical from the perspective of the host as well as the container. Since the Dockerfile is rootless and runs as the app user, it doesn't have the permissions to read the mounted volume:
x-app: &app
...
volumes:
...
- .:/app/samvera/hyrax-webapp <---------------------------------------------Our group is also exploring this stack on our Linux workstations and found that commenting out the line indicated above resulted in a working environment.
orangewolf
commented
1 year ago @adamhgriffith-uofu yes, if you remove the bind mount it works ok... but you don't get to edit code outside the container and have it work inside the container. That's ok for a production deployment but makes development very awkward. The good news is that we have a new solution for this using the user id that seems to be successful more uniformly. I'll try to get a PR up about it early next week.
ryan-lang
commented
5 months ago @orangewolf Have there been any updates on this issue?
Problem: service "initialize_app" didn't completed successfully and therefore prevent other services from starting
Expected behavior: service "initialize_app" completes successfully so that the following services will be started
Environment:
Output:
See below excerpts from log (initialize_app), see full log here: log.txt
Observations:
a) The error
seems to be triggered in all cases during execution of the following migration step:
b) Migration steps located before and after "20210121233027_add_themes_to_sites.rb" are executed without triggering any errors.
c) Everything seems to work fine in Ubuntu 20.04 - WSL2. Containers start without error: