Skip to content

Conversation

@studebacon
Copy link

The production django container would get stuck in a restart loop due do a lack of permission on the /app/ghostwriter/media folder.

Running mkdir /app/ghostwriter/media prior to chown -R django /app in the Dockerfile corrects this issue.

…p due do a lack of permission on the /app/ghostwriter/media folder.

Running mkdir /app/ghostwriter/media prior to chown -R django /app in the Dockerfile corrects the issue.
@Kaicastledine
Copy link

Had the same issue. Logs found:

mkdir: can't create directory '/app/ghostwriter/media/evidence': Permission denied
mkdir: can't create directory '/app/ghostwriter/media/user_avatars': Permission denied
mkdir: can't create directory '/app/ghostwriter/media/templates': Permission denied
cp: can't create '/app/ghostwriter/media/templates': Permission denied
PostgreSQL is available
mkdir: can't create directory '/app/ghostwriter/media/evidence': Permission denied
mkdir: can't create directory '/app/ghostwriter/media/user_avatars': Permission denied
mkdir: can't create directory '/app/ghostwriter/media/templates': Permission denied

Symptons:

bca6682deff8   ghostwriter_production_nginx      "/docker-entrypoint.…"   14 seconds ago   Restarting (1) 3 seconds ago              ghostwriter_nginx_1
e58913957285   ghostwriter_production_django     "/entrypoint /start"     15 seconds ago   Restarting (1) 1 second ago               ghostwriter_django_1

Updating the dockerfile for django as instructed above fixed the issue

@chrismaddalena
Copy link
Collaborator

@studebacon @Kaicastledine Someone else mentioned an issue (off GitHub) that could be related to this. I looked into with them and we determined the container had built incorrectly. I have not encountered it myself, but this seems to be a rare issue caused by the build going a bit sideways.

I'm not opposed to working around a rare permissions snafu with a chown, but I am curious if this started occurring out of the blue and when.

@Kaicastledine
Copy link

@studebacon @Kaicastledine Someone else mentioned an issue (off GitHub) that could be related to this. I looked into with them and we determined the container had built incorrectly. I have not encountered it myself, but this seems to be a rare issue caused by the build going a bit sideways.

I'm not opposed to working around a rare permissions snafu with a chown, but I am curious if this started occurring out of the blue and when.

So this was a new issue with the last release, if that's any help.

@chrismaddalena
Copy link
Collaborator

Yep! That does help. With the latest release, we bumped up versions of a few things, including the Alpine Linux image. That might explain the appearance of a rare filesystem bug like this. This PR is likely the best way for the project to address it.

@arledesma
Copy link

This is a race condition with the nginx container. The nginx container is defaulted to USER root, mounting the volume before django, and subsequently the docker-compose shorthand syntax for volumes is not set for read_only or volume: nocopy.

chrismaddalena added a commit to chrismaddalena/Ghostwriter that referenced this pull request May 10, 2021
chrismaddalena added a commit to chrismaddalena/Ghostwriter that referenced this pull request May 10, 2021
Enhancement: Incorporating PRs GhostManager#143, GhostManager#152, and GhostManager#158

See merge request ghostmanager/Ghostwriter!114
@chrismaddalena
Copy link
Collaborator

That's interesting, @arledesma. It makes sense. A race condition would explain why it's not easily reproduced and wasn't reported by others. I included this patch in the latest release, v2.2, but I'm curious to see where your WIP #163 goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants