Fails to install/start using Podman

[burgeda]

Describe the bug
After running podman compose up -d on the yaml file the image is downloaded and the container starts to run; however, when viewing the logs, there is a series of critical errors and the application does not finish setting up, then exits, before looping the whole thing again, and again. The error (view snippet section) mentions a permission issue on an internal folder (inside the container, not the host machine), before saying the data directory needs permissions and to use a chown command. Even once I use the chown command and try again

I HAVE used sudo to change the ownership on the host system as suggest, didn't make any difference and it was already owned by 1000:1000

To Reproduce
Steps to reproduce the behavior:

Create a compose.yaml as described in the installation steps.
Run container.
Look at logs.

Expected behavior
I expect the container to install correctly and display a webpage for me.

Screenshots
If applicable, add screenshots to help explain your problem.

Spoolman Host (please complete the following information):

• Installation type: podman
• Installed version: latest as of 2024-11-24
• OS and Distro: Fedora
• Database type: sqlite

docker-compose.yml

---

services:
spoolman:
image: ghcr.io/donkie/spoolman:latest
container_name: spoolman
environment:
- TZ=America/Toronto # Optional, defaults to UTC
volumes:
# Mount the host machine's ./data directory into the container's /home/app/.local/share/spoolman directory
- type: bind
source: /home/SECRET/spoolman2/data
target: /home/app/.local/share/spoolman # Do NOT change this line
ports:
- 7912:8000
restart: unless-stopped

Output

podman start -a spoolman
[spoolman] | usermod: no changes
[spoolman] | User UID: 1000
[spoolman] | User GID: 1000
[spoolman] | Starting uvicorn...
Failed to setup disk-based cache due to permission error. Ensure the path /home/app/.local/share/spoolman/cache/hishel is writable. Using in-memory cache instead as fallback.
INFO: Started server process [1]
INFO: Waiting for application startup.
spoolman.env WARNING Data directory is not writable, trying to fix it...
chown: cannot read directory '/home/app/.local/share/spoolman': Permission denied
spoolman.env ERROR Data directory is not writable. Please run "sudo chown -R 1000:1000 /path/to/spoolman/datadir" on the host OS.
ERROR: Traceback (most recent call last):
File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 732, in lifespan
async with self.lifespan_context(app) as maybe_state:
File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 608, in aenter
await self._router.startup()
File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 709, in startup
await handler()
File "/home/app/spoolman/spoolman/main.py", line 117, in startup
env.check_write_permissions()
File "/home/app/spoolman/spoolman/env.py", line 391, in check_write_permissions
sys.exit(1)
SystemExit: 1

ERROR: Application startup failed. Exiting.

[Donkie]

I've spent an hour trying to get Spoolman working with podman (which I've never used before) but there seem to be issues with permissions definitely. The only way I got it working is by simply running it with rootful podman, so like

sudo podman-compose up -d

did you try that?

[burgeda]

Defeats the whole purpose of podman.  Podman was designed and built to be rootless. 

…

---- On Mon, 25 Nov 2024 13:44:07 -0500 ***@***.*** wrote ---- I've spent an hour trying to get Spoolman working with podman (which I've never used before) but there seem to be issues with permissions definitely. The only way I got it working is by simply running it with rootful podman, so like sudo podman-compose up -d did you try that? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[Donkie]

Sure, but I don't use it and thus don't know how to support it. Feel free to submit a pull request with the changes needed to make it work.

[burgeda]

Well, I know less about programming than you know about podman ;-) so ... I won't be generating a pull request. Thanks for trying.

…

---- On Mon, 25 Nov 2024 16:10:10 -0500 Donkie ***@***.***> wrote --- Sure, but I don't use it and thus don't know how to support it. Feel free to submit a pull request with the changes needed to make it work. — Reply to this email directly, #546 (comment), or https://github.com/notifications/unsubscribe-auth/AUOUH6452JMFILPDAOVYLG32COG3FAVCNFSM6AAAAABSMLFZPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJZGA2DANBSGQ. You are receiving this because you authored the thread.

[schoentoon]

The problem is that podman will remap the root user inside the container to the regular user outside of the container. Because of this images that are build to run as the root user by default tend to just work. However the image of spoolman does user switching for you, which causes permission issues because of this. There's the very useful --userns keep-id because of this (where the container would run under the same user id as you have outside of the container, instead of as root).. But that doesn't work either because of the user switching part. I got it to work quite easily by just ignoring the build in entrypoint that does the user switching. As in, the following command works for me.
podman run --userns keep-id --entrypoint uvicorn -v /tmp/spoolman/:/home/app/.local/share/spoolman -p 8000:8000 -it --rm ghcr.io/donkie/spoolman:latest spoolman.main:app --host ${SPOOLMAN_HOST:-0.0.0.0} --port ${SPOOLMAN_PORT:-8000} "$@"

Do however keep in mind that with this approach, defining SPOOLMAN_HOST or SPOOLMAN_PORT as environment variables inside the container won't do anything, as it's evaluated earlier already.