[BUG] `SQLiteError: unable to open database file` when running with podman compose

[yushisora]

Describe the bug
The container cannot start with SQLiteError: unable to open database file when running with podman compose.

Affects:

• Standalone mode

To Reproduce
Steps to reproduce the behavior:

1. start container with podman-compose up -d

Expected behavior
the container starts

Additional context
Here is the error log:

220 |           onconnect(null);
221 |       } catch {
222 |       }
223 |     } catch (err) {
224 |       if (err && typeof err === "object" && "name" in err && err.name === "SQLiteError") {
225 |         this.storedError = new SQLiteError(message, { code, errno, byteOffset });
                                 ^
SQLiteError: unable to open database file
      errno: 14,
 byteOffset: -1,
       code: "SQLITE_CANTOPEN"

      at new SQLiteAdapter (internal:sql/sqlite:225:28)
      at adapterFromOptions (bun:sql:11:14)
      at new SQL2 (bun:sql:17:117)
      at initDb (/usr/src/app/src/db.js:14:8)
      at initDb (/usr/src/app/src/db.js:11:22)
      at /usr/src/app/src/db.js:78:12

Bun v1.3.2 (Linux x64 baseline)

This is my compose.yml which is executed by podman compose:

services:
  cap:
    image: docker.io/tiago2/cap:latest
    container_name: cap
    ports:
      - 3000:3000
    network_mode: pasta
    env_file: .env
    volumes:
      - ./data:/usr/src/app/.data

[GochoMugo]

Faced same error when using docker compose. Fixed it with chown 1000:1000 ./data.

[yushisora]

Faced same error when using docker compose. Fixed it with chown 1000:1000 ./data.

In my case, an empty data directory is created automatically after running podman-compose up -d and its owner and group is already set as 1000:1000. But still it has the same issue.

[ancashoria]

Turns out it is not an issue with CapJS, but a permission issue that can be fixed by the one who runs the container.

In my case, that's Kubernetes which was running the PersistentVolume as root and the container as something else. That made the container unable to write to the PersistentVolume.

In my Deployment I had to add. Setting it runs the Pod and the PV as the same user and it works then.

securityContext:
    fsGroup: 1234

[yushisora]

@ancashoria you have point me to the right direction. I try running the container with an internal volume instead of an external persistent volume and it starts successfully.