Docker image fails to run properly due to permission issues, using podman

[jessienab]

Steps to reproduce

1. Pull the docker-compose.yml file
2. Modify as needed
3. Launch using podman-compose up -d in the same folder as the .yml file
4. Komga will fail due to permission issues and cycle through restarts.

Expected behavior

Komga should start up properly and be accessible over the system.

Actual behavior

Komga will continuously cycle through it's startup process due to it failing to write a .lock file, and failure to write and read an sqlite database.

Logs

2022-04-27 19:13:15.224 WARN 1 --- [ main] org.apache.activemq.artemis.core.server : AMQ222141: Node Manager can not open file /config/artemis/journal/server.lock

java.io.IOException: No such file or directory

and

java.sql.SQLException: opening db: '/config/database.sqlite': Permission denied

Full log attached. komga-error.log

Komga version

0.154.1

Operating system

Arch Linux 5.16.14-arch1-1

Other details

I am using podman in rootless mode, and I understand that presumably podman is not supported compared to Docker.

However, my understanding is that podman is effectively compliant or compatible with most/all docker containers, potentially excluding situations like this with permission issues.

The error here seems to be failure to write files to a specific folder, as it's owned by root inside the container, thus perhaps the expectation that the container would be run "as root" (which docker does normally). My personal suggestion in this case would be to modify the /config folder permission to a general access user, or somehow map it to the container running user's ID.

Here are my relevant config files and user IDs. I appreciate any help if it's possible, otherwise I can attempt running this by building a custom image, or as a bare metal system app.

Thanks!

---

docker-compose.yml: modified to read cleaner, change system-side port, and user to the container user. Timezone is set from environment variable.

---
version: '3.3'
services:
  komga:
    image: gotson/komga
    container_name: komga
    volumes:
      - /etc/container-config/komga/config:/config
      - /mnt/data/comics/:/data
    ports:
      - 12345:8080
    user: "1001:1001"
    environment:
      - LOGGING_LEVEL_ORG_GOTSON_KOMGA=DEBUG
      - TZ=Europe/Berlin
    restart: unless-stopped

drwxr-xr-x 1 root root 14 Mar 21 03:18 /etc/ drwxr-xr-x 1 containeru containeru 72 Apr 26 23:32 /etc/container-config/ drwxr-xr-x 1 containeru containeru 12 Apr 27 18:51 /etc/container-config/komga/ drwxr-xr-x 1 containeru containeru 0 Apr 27 18:51 /etc/container-config/komga/config/

$ podman exec -it komga /bin/bash 1001@c42372a5033e:~$

showing that the user is set to the correct ID

$ id uid=1001(containeru) gid=1001(containeru) groups=1001(containeru)

showing the user id matches the user running containers

Acknowledgements

• [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I have checked the FAQ.
• [X] I have updated the app to the latest version.
• [X] I will fill out all of the requested information in this form.

[gotson]

I don't know podman, but when using docker, and specifying the user in the compose file, the mounts you provide must also be accessible by that user.

IMO it seems to be a problem with the mounts and user rights, not with the container image itself. There is nothing in the container image expecting root at any time, so i don't think that's coming from there.

---

The error here seems to be failure to write files to a specific folder, as it's owned by root inside the container

The files are not owned by root, if you supply the right user with Docker for instance, those files are owned by the provided user.

My personal suggestion in this case would be to modify the /config folder permission to a general access user, or somehow map it to the container running user's ID.

That's what the user field in the docker compose do, there's nothing to change in the Docker image.

---

I would say it's a Podman configuration issue with the user and the mounts, i would suggest you investigate in that direction.

I won't be spending time on Podman myself, so don't expect any investigation from my end.

[nattycleopatra]

podman-compose is pretty buggy compared to docker-compose. In most cases you'd be better off running Podman's Docker v2 API service and just using regular docker-compose with it instead.

A useful test you could do in the container would be trying to write to the path Komga is failing on, for instance by running touch /config/test. I assume this would give you a permission denied error under the conditions shown in your issue report.

Are you using SELinux? Containers won't be able to write to a directory if labels aren't set up for this context regardless of owner/group, see the documentation for podman run --volume for details on that.

[briandking]

Using the USER option with podman to set the user inside a container, does not use the same user outside the container. It creates a new user that exists only inside that container, within the namespace of the user running the podman command.

Using it without the USER option will run the processes inside the contain as the user that is running the podman command, which might be what you want?

You might want to take a read through: https://www.tutorialworks.com/podman-rootless-volumes/ Especially the section "How to allow a rootless podman container to write to a volume". ... and also review https://www.redhat.com/sysadmin/debug-rootless-podman-mounted-volumes

Short version, you might be able to get it to work using the USER option like you have, if you also add the :Z,U options to the volumes to account for SELinux and Userspaces.

Make sure you read the caveats in the redhat link's "Second Solution" section before using the U option.

Komga ran fine for me in a quick test with podman, so your issue is definitely a local permissions issue and not a komga compatibility issue with podman.

I simply started the pod as a non root user who had access to the config and data directories, and dropped the USER option from the docker compose yaml. E.g.

podman run --rm -p 12345:8080 -v /data/komga/config:/config -v /data/komga/comics/:/data docker.io/gotson/komga

[jessienab]

Hi, Really not sure what changed, but Komga works fine now. Using latest podman pull of the container image.

I set the komga/config folder to have 777 permissions; overkill, but I'll rework it. My assumption is that the Other section needs write permissions, again to be reworked as the running user should be fine . Overall, yes it was a permission issue that I need to revisit, but for now at least I know this is NOT a podman or container issue.

Apologies, and thanks!