[bug]: chown in docker entrypoint causes mounting of config to no longer be possible

[lrstanley]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

Operating system

Linux

GPU vendor

Nvidia (CUDA)

GPU model

P40

GPU VRAM

24GB

Version number

4.1.0

Browser

n/a

Python dependencies

No response

What happened

Looks as though during startup, within the docker entrypoint, a chown is now ran to ensure permissions are setup correctly for the runtime directory. This occurred in this commit:

https://github.com/invoke-ai/InvokeAI/commit/b00e27b02275465fc4fafc6344dfacd48ee1fc95

For those who run InvokeAI with a read-only mounted configuration file (Docker, Kubernetes -- in my case, Kubernetes), this will cause the container to crash and exit early, as chown isn't able to change the permissions. Example error:

chown: changing ownership of '/invokeai/invokeai.yaml': Read-only file system

What you expected to happen

I would hope that this pattern could continue to work, as it makes deploying InvokeAI outside of my desktop and into a cluster more predictable. Would be convenient to have an environment variable, something like FIX_PERMISSIONS=false, that would skip that portion, for those who know their permissions are setup correctly.

How to reproduce the problem

Use Docker or Kubernetes to mount /invokeai/invokeai.yaml as read-only, and do a standard startup inside of the docker container.

Additional context

No response

Discord username

No response

[lrstanley]

This is my temporary solution for now -- before building and pushing the image to a container registry, I just revert the patch in question:

git apply -R https://github.com/invoke-ai/InvokeAI/commit/b00e27b02275465fc4fafc6344dfacd48ee1fc95.patch

[ebr]

Thanks - good catch. This docker setup is more tailored to desktop use, where this chown is needed to prevent permission unpleasantries. However, we could ignore the failure to change permissions in the entrypoint, e.g. with chown ... || true. Would that work for you?

FWIW, in your case it might be easiest to set ....containers.command: ["invokeai-web"] and this way bypass the entrypoint altogether. Just as an option.

[lrstanley]

FWIW, in your case it might be easiest to set ....containers.command: ["invokeai-web"] and this way bypass the entrypoint altogether. Just as an option.

I attempted this before (though this was last major version, and before some of the more recent configuration changes), and with the previous entrypoint it didn't initialize as expected. Given all of the initialization/configure calls have been removed from the entrypoint, I think for my case, this should now work.

Do still think the chown could be problematic for others though.