I wanted to run this container in rootless docker and also mount the 2 folders that in the default docker-compose.yaml are volumes as folders in the current user fs instead.
I usually achieve this by using containers that let you set the UID and GID that will be used inside the container by the actual program, I tried to set PUID GUID and 0 (seeing this container supports those env variables) so that the main program would run as the root user and group inside the container (in rootless docker that corrisponds to the host user and group docker is running as), that allows me to access the container files with the host user the container it's running under, this usually works without any problems and it's quite easy to do with images like linuxserver.io ones.
The problem is that using this docker-compose.yaml:
name: scriberr
services:
scriberr:
container_name: scriberr
image: ghcr.io/rishikanthc/scriberr:v1.2.0
ports:
- "8080:8080"
volumes:
- ./scriberr-data:/app/data # bind mount for generic scriberr data
- ./python-environments-and-models-data:/app/whisperx-env # bind mount for models and python envs
environment:
- PUID=0
- PGID=0
- APP_ENV=production # DO NOT CHANGE THIS
# CORS: comma-separated list of allowed origins for production
# - ALLOWED_ORIGINS=https://your-domain.com
# - SECURE_COOKIES=false # Uncomment this ONLY if you are not using SSL
restart: unless-stopped
on first start I get the error:
failed to connect to database: unable to open database file: out of memory (14)
whenever starting the container.
full container log:
scriberr | === Scriberr Container Setup ===
scriberr | Requested UID: 0, GID: 0
scriberr | Setting up custom user with UID=0, GID=0...
scriberr | Group with GID 0 already exists, using it
scriberr | Warning: Could not change user ID, continuing with existing user
scriberr | Setting up data directories...
scriberr | === Setup Complete ===
scriberr | Switching to user appuser (UID=0, GID=0) and starting application...
scriberr | time=14:03:32 level="INFO " msg="Starting Scriberr" version=dev
scriberr | [+] Loading configuration
scriberr | time=14:03:32 level="INFO " msg="Registering adapters with environment path" whisperx_env=/app/whisperx-env
scriberr | time=14:03:32 level="INFO " msg="Adapter registration complete"
scriberr | [+] Connecting to database
scriberr | time=14:03:32 level=ERROR msg="Failed to connect to database" error="failed to connect to database: unable to open database file: out of memory (14)"
scriberr exited with code 1 (restarting)
scriberr | === Scriberr Container Setup ===
scriberr | Requested UID: 0, GID: 0
scriberr | Setting up custom user with UID=0, GID=0...
scriberr | Group with GID 0 already exists, using it
scriberr | Warning: Could not change user ID, continuing with existing user
scriberr | Setting up data directories...
scriberr | === Setup Complete ===
scriberr | Switching to user appuser (UID=0, GID=0) and starting application...
scriberr | time=14:03:37 level="INFO " msg="Starting Scriberr" version=dev
scriberr | [+] Loading configuration
scriberr | time=14:03:37 level="INFO " msg="Registering adapters with environment path" whisperx_env=/app/whisperx-env
scriberr | time=14:03:37 level="INFO " msg="Adapter registration complete"
scriberr | [+] Connecting to database
scriberr | time=14:03:37 level=ERROR msg="Failed to connect to database" error="failed to connect to database: unable to open database file: out of memory (14)"
scriberr exited with code 1 (restarting)
[... trimmed as it's just the same thing over and over ..]
I see that rootless docker is not mentioned anywhere in this repository so I'm guessing that it probably was not tested as a usecase.
I see no commits referencing this exact problem.
by changing the start command to id we can see that something went wrong as it's using UID and GID 1000 instead of the requested 0:
docker run -it -e PUID=0 -e PGID=0 --rm ghcr.io/rishikanthc/scriberr:v1.2.0 id
=== Scriberr Container Setup ===
Requested UID: 0, GID: 0
Setting up custom user with UID=0, GID=0...
Group with GID 0 already exists, using it
Warning: Could not change user ID, continuing with existing user
Setting up data directories...
=== Setup Complete ===
Switching to user appuser (UID=0, GID=0) and starting application...
uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
It seems to fail because the entrypoint script (docker-entrypoint.sh) fails to setup_user with UID 0 becuase it already exists because it's the root user.
If this gets fixed it would also be nice to add a section in the readme regarding this exact usecase with docker rootless but that's for the future.
I wanted to run this container in rootless docker and also mount the 2 folders that in the default
docker-compose.yamlare volumes as folders in the current user fs instead.I usually achieve this by using containers that let you set the
UIDandGIDthat will be used inside the container by the actual program, I tried to setPUIDGUIDand0(seeing this container supports those env variables) so that the main program would run as the root user and group inside the container (in rootless docker that corrisponds to the host user and group docker is running as), that allows me to access the container files with the host user the container it's running under, this usually works without any problems and it's quite easy to do with images like linuxserver.io ones.The problem is that using this
docker-compose.yaml:on first start I get the error:
whenever starting the container.
full container log:
I see that rootless docker is not mentioned anywhere in this repository so I'm guessing that it probably was not tested as a usecase.
I see no commits referencing this exact problem.
by changing the start command to
idwe can see that something went wrong as it's usingUIDandGID1000instead of the requested0:docker run -it -e PUID=0 -e PGID=0 --rm ghcr.io/rishikanthc/scriberr:v1.2.0 idIt seems to fail because the entrypoint script (
docker-entrypoint.sh) fails to setup_user withUID0becuase it already exists because it's the root user.If this gets fixed it would also be nice to add a section in the readme regarding this exact usecase with docker rootless but that's for the future.