Having to use a named volume in production

[SHxKM]

This is more my lackluster understanding than anything else.

Previously I was hosted on Railway and couldn't use the compose.yaml from this template (which I've adopted). I'm now moving to Hetzner + Dokploy, and bin/docker-entrypoint-web is failing:

Found another file with the destination path 'admin/js/jquery.init.js'. It will be ignored since only the first encountered file is collected. If this is not what you want, make sure every static file has a unique path.
0 static files copied to '/public_collected', 400 unmodified, 1547 post-processed.
Collectstatic completed
cp: cannot create regular file '/app/public_collected/youtubemusic.svg': Permission denied

I believe it's this line:

# Always keep this here as it ensures your latest built assets make their way
# into your volume persisted public directory.
cp -r /public_collected /app

Claude claims this is because Dokploy runs as root, and so this directory is owned by root and the user python can't write to it. It's suggesting I create a named volume. Is that the way to go?

[nickjj]

Hi,

I don't know what your set up is like on Hetzner with Dokploy but what user are you running this as? Run id when logged in as that user.

If the uid and gid is not 1000:1000, that could be the problem. It would be easy to fix, you need to build and run your project with a UID that matches your system. The .env file has this documented:

docker-django-example/.env.example

Line 23 in 25de410

# By default these values get populated by $UID / $GID and if unset then they

Typically the first non-root user on a Linux system is 1000:1000 by default so no adjustments are needed.

I never heard of Dokploy so I'm not sure what it's doing behind the scenes. Usually to run Docker on a server you would install it and then assign your non-root user to the docker group, and then you can run Docker commands without root and all permissions would work as long as the UID / GID is lined up (when bind volumes are involved).

Ultimately this is all related to the bind volume for the public directory so you can mount it into nginx not running in a container. If you didn't care about that or you have other ways to host static files you can remove that volume all together and it will work with no further adjustments.

[SHxKM]

Thanks for your helpful answer as always @nickjj.

I don't know what your set up is like on Hetzner with Dokploy but what user are you running this as? Run id when logged in as that user.

This is what I get when I run id from inside the container:

uid=1000(python) gid=1000(python) groups=1000(python)

I never heard of Dokploy so I'm not sure what it's doing behind the scenes. Usually to run Docker on a server you would install it and then assign your non-root user to the docker group, and then you can run Docker commands without root and all permissions would work as long as the UID / GID is lined up (when bind volumes are involved).

I think this is the key distinction. Dokploy runs as root and probably that affects how Docker works.

Ultimately this is all related to the bind volume for the public directory so you can mount it into nginx not running in a container. If you didn't care about that or you have other ways to host static files you can remove that volume all together and it will work with no further adjustments.

Yeah. I just realized app/src's whole purpose is for when we're not using WhiteNoise.

I tried to do something I couldn't do in #68, which is run collectstatic on build time, but I have (as I stated there) 10+ mandatory env vars and this will become unwieldy to keep collecstatic in Dockerfile. Instead, I ended up always creating in Dockerfile:

RUN mkdir -p /app/public_collected

And having a named volume in compose.yaml:

public_collected: {}  # named volume for the web service -- see x-app volumes note

And I changed the volumes section:

volumes:
    # NOTE: diverges from docker-django-example, which defaults this to a host
    # bind mount (`./public_collected:...`). A bind mount is writable by the
    # container only if the host dir is owned by the container user -- true on
    # a dev laptop, false under Dokploy (which clones the repo as root). The
    # non-root container then can't write it, and docker-entrypoint-web's `cp`
    # crash-loops the service. A named volume inherits ownership from the
    # image dir (the Dockerfile creates /app/public_collected python-owned).
    # Dev is unaffected: .env sets DOCKER_WEB_VOLUME=.:/app, overriding this.
    - "${DOCKER_WEB_VOLUME:-public_collected:/app/public_collected}"

[nickjj]

This is what I get when I run id from inside the container:

Sorry, for clarity I meant to run id from logging into your server, not the container, but if Dokploy is running your container as the root user, that seems a little alarming. Do they let you pick which Linux user executes the Docker commands?

[nickjj]

Btw for the volumes you don't need to modify the compose.yaml file directly.

You can define DOCKER_WEB_VOLUME to override it in the .env file. It is documented here: https://github.com/nickjj/docker-flask-example/blob/0f36a9d7965e652c4b675053c8ccdf2de2170d7f/.env.example#L110

[SHxKM]

Sorry, for clarity I meant to run id from logging into your server, not the container,

That would be uid=0(root) gid=0(root) groups=0(root) because I'm currently logging to the root user.

but if Dokploy is running your container as the root user, that seems a little alarming. Do they let you pick which Linux user executes the Docker commands?

I don't want to mislead. Maybe this isn't the case and I'm wrong here.

[nickjj]

That would be uid=0(root) gid=0(root) groups=0(root) because I'm currently logging to the root user.

Right, you would want to login as the same user that Dokploy is using, or more generally the user you're running Docker Compose commands as. Separate to that, you'd want to check into how Dokploy is running your containers (as root with sudo, etc.) or some other way.