AUTOMATIC1111: Enable running as non root user. #546
Conversation
Expose build args to container which allow the web service
to run as given uid:gid.
By default, this behavior is "off". Building via docker compose still
defaults to root:root on everything. Unless these args are explicitly
set, no users should notice a difference.
Build arguments are also exposed as Docker environment variables, so they can
be freely referenced in the `entrypoint.sh`
Output files will be owned by PUID and PGID, so if set, no more root:root
images (unless desired).
New arguments:
- ARG PUID=0
- ARG PGID=0
- ARG USER_HOME=/root
New environment variable:
- RSYNC_FLAGS
- NFS share doesn't like `-a` changing every bit on a directory
Example docker-compose.override.yaml using these flags
```
version: '3.9'
services:
auto:
environment:
RSYNC_FLAGS: -vrlgotO
build:
args:
USER_HOME: /opt/stablediffusion
PUID: 1000
PGID: 1002
volumes:
- /media/data:/data
- /tmp:/output
download:
volumes:
- /media/data:/data
```
|
Thanks, does this work on windows? |
|
Hey, thanks for getting back to me. I'm fairly sure it will work fine on Windows, but I can't say for sure. I don't have a non-virtualized Windows installation handy to test currently. Docker is implemented in a VM on Windows (and mac) anyhow, so I don't see why it would care about unix permissions. Also yes, it is easy to execute things as root in a running with docker exec. EG: docker exec -it \
--user root \
stablediffusion \
apt install -y foo bar bazOf course, this would have no persistence (which I believe is the same case now), so some key directories might need to be added as volumes or someone would have to use this image as a base to install their desired extra packages. |
|
Awesome, this works for me! This has bugged me for a while and was just about to try and work on this myself. Great work! |
|
Sorry for coming back late to this one. Regarding this:
Currently, we achieve "persistence" by using a Is is possible to use the non-root container in a way that is compatible with this solution? what other alternatives we have? |
Hello again, So I'm not sure if there's an elegant solution involving non-root containers and installing packages at runtime. Several options exist (adding sudo maybe?), but I think the most reasonable solution might be adding an extra build argument to install user specified debs. Since a user would have to specify non-root build args anyway to build this container as unprivileged, I would suggest we add something like I'm not sure how often people add or remove packages to their containers, but this seems like an okay workaround. |
Expose build args to container which allow the web service to run as given uid:gid.
Recent commits have broken my SD model NFS share, so I've decided to try and fix the problem.
Not sure if anyone else wants these changes, but here they are. They are tested and working to the best
of my ability.
By default, this behavior is "off". Building via docker compose still defaults to root:root on everything. Unless these args are explicitly set, no users should notice a difference.
Build arguments are also exposed as Docker environment variables, so they can be freely referenced in the
entrypoint.shOutput files will be owned by PUID and PGID, so if set, no more root:root images (unless desired).
New arguments:
New environment variable:
-achanging every directory bitExample docker-compose.override.yaml using these flags