The database settings are invalid: database is locked (arm64) #3390

New Issue

GiteaMirror · 2025-11-02T05:11:23-06:00

GiteaMirror commented

2025-11-02 05:11:23 -06:00

Originally created by @LukeShortCloud on GitHub (May 29, 2019).

Gitea version (or commit ref): 1.7.6 and 1.8.1
Operating system: Alpine 3.8.0 (ARM64)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: There are no log files generated. Here is the stdout of the gitea process as I attempt to do the install a few times: https://gist.github.com/ekultails/c5b674147716b3fd35c2402e7f1a07a3

Description

When deploying Gitea for the first time on Kubernetes using the default settings, the installation runs for about a minute and then fails saying "The database settings are invalid: database is locked". The database file is created but it is completely empty. This happens with other versions of Gitea as well. The files in the volume are all created and owned by the user with UID 1000 (rock64).

$ ls -lah /exports/gitea
total 20K
drwxr-xr-x 5 rock64 rock64 4.0K May 29 01:51 .
drwxr-xr-x 8 root   root   4.0K May 29 01:48 ..
drwxr-xr-x 3 rock64 rock64 4.0K May 29 01:51 git
drwxr-xr-x 4 rock64 rock64 4.0K May 29 02:19 gitea
drwx------ 2 root   root   4.0K May 29 01:51 ssh
$ ls -lah /exports/gitea/gitea/
total 16K
drwxr-xr-x 4 rock64 rock64 4.0K May 29 02:19 .
drwxr-xr-x 5 rock64 rock64 4.0K May 29 01:51 ..
drwxr-xr-x 2 rock64 rock64 4.0K May 29 01:51 conf
-rw-r--r-- 1 rock64 rock64    0 May 29 01:53 gitea.db
drwxr-xr-x 2 rock64 rock64 4.0K May 29 01:51 log

Kubernetes deployment file:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitea-deployment
  labels:
    app: gitea
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gitea
  template:
    metadata:
      labels:
        app: gitea
    spec:
      volumes:
        - name: gitea-pvc
          persistentVolumeClaim:
            claimName: gitea-volume-claim
      containers:
        - name: gitea
          image: kunde21/gitea-arm:arm64-v1.7.6
          environment:
            - USER_UID=1000
            - USER_GID=1000
          restart: always
          ports:
            - containerPort: 3000
              name: gitea-http
            - containerPort: 22
              name: gitea-ssh
          volumeMounts:
            - mountPath: /data
              name: gitea-pvc

Originally created by @LukeShortCloud on GitHub (May 29, 2019). - Gitea version (or commit ref): 1.7.6 and 1.8.1 - Operating system: Alpine 3.8.0 (ARM64) - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: There are no log files generated. Here is the stdout of the gitea process as I attempt to do the install a few times: https://gist.github.com/ekultails/c5b674147716b3fd35c2402e7f1a07a3 ## Description When deploying Gitea for the first time on Kubernetes using the default settings, the installation runs for about a minute and then fails saying "The database settings are invalid: database is locked". The database file is created but it is completely empty. This happens with other versions of Gitea as well. The files in the volume are all created and owned by the user with UID 1000 (rock64). ``` $ ls -lah /exports/gitea total 20K drwxr-xr-x 5 rock64 rock64 4.0K May 29 01:51 . drwxr-xr-x 8 root root 4.0K May 29 01:48 .. drwxr-xr-x 3 rock64 rock64 4.0K May 29 01:51 git drwxr-xr-x 4 rock64 rock64 4.0K May 29 02:19 gitea drwx------ 2 root root 4.0K May 29 01:51 ssh $ ls -lah /exports/gitea/gitea/ total 16K drwxr-xr-x 4 rock64 rock64 4.0K May 29 02:19 . drwxr-xr-x 5 rock64 rock64 4.0K May 29 01:51 .. drwxr-xr-x 2 rock64 rock64 4.0K May 29 01:51 conf -rw-r--r-- 1 rock64 rock64 0 May 29 01:53 gitea.db drwxr-xr-x 2 rock64 rock64 4.0K May 29 01:51 log ``` Kubernetes deployment file: ``` --- apiVersion: apps/v1 kind: Deployment metadata: name: gitea-deployment labels: app: gitea spec: replicas: 1 selector: matchLabels: app: gitea template: metadata: labels: app: gitea spec: volumes: - name: gitea-pvc persistentVolumeClaim: claimName: gitea-volume-claim containers: - name: gitea image: kunde21/gitea-arm:arm64-v1.7.6 environment: - USER_UID=1000 - USER_GID=1000 restart: always ports: - containerPort: 3000 name: gitea-http - containerPort: 22 name: gitea-ssh volumeMounts: - mountPath: /data name: gitea-pvc ```

GiteaMirror closed this issue

2025-11-02 05:11:23 -06:00

GiteaMirror commented

2025-11-02 05:11:24 -06:00

@lafriks commented on GitHub (May 29, 2019):

please update to latest version

@lafriks commented on GitHub (May 29, 2019): please update to latest version

GiteaMirror commented

2025-11-02 05:11:24 -06:00

@lunny commented on GitHub (May 29, 2019):

How many replications are you running?

@lunny commented on GitHub (May 29, 2019): How many replications are you running?

GiteaMirror commented

2025-11-02 05:11:24 -06:00

@LukeShortCloud commented on GitHub (May 30, 2019):

I have tried versions 1.6.4, 1.7.6, and 1.8.1. All of them have the same issue. Replicas are set to 1 and I have verified that there is only one container running.

@LukeShortCloud commented on GitHub (May 30, 2019): I have tried versions 1.6.4, 1.7.6, and 1.8.1. All of them have the same issue. Replicas are set to 1 and I have verified that there is only one container running.

GiteaMirror commented

2025-11-02 05:11:24 -06:00

@LukeShortCloud commented on GitHub (Jun 27, 2019):

It works without a problem using 1.8.3 on baremetal. I believe the issue is with the permissions inside the container. I will close this and comment back if I ever figure out the exact workaround for my setup.

@LukeShortCloud commented on GitHub (Jun 27, 2019): It works without a problem using 1.8.3 on baremetal. I believe the issue is with the permissions inside the container. I will close this and comment back if I ever figure out the exact workaround for my setup.

GiteaMirror commented

2025-11-02 05:11:24 -06:00

@shawn-bandy-urbag commented on GitHub (Jul 21, 2019):

If it helps, I ran into much the same issue and it appears, for me, to be have been related to the underlying nfs share locking. I'm also running on arm64.

@shawn-bandy-urbag commented on GitHub (Jul 21, 2019): If it helps, I ran into much the same issue and it appears, for me, to be have been related to the underlying nfs share locking. I'm also running on arm64.

GiteaMirror commented

2025-11-02 05:11:25 -06:00

@framuc commented on GitHub (Apr 30, 2020):

If it helps, I ran into much the same issue and it appears, for me, to be have been related to the underlying nfs share locking. I'm also running on arm64.

Hi, it seems you are right. It works locally for me but as soon as I use a nfs mout I get the same error. Dif you find any solution for this?

@framuc commented on GitHub (Apr 30, 2020): > > > If it helps, I ran into much the same issue and it appears, for me, to be have been related to the underlying nfs share locking. I'm also running on arm64. Hi, it seems you are right. It works locally for me but as soon as I use a nfs mout I get the same error. Dif you find any solution for this?

GiteaMirror commented

2025-11-02 05:11:25 -06:00

@shawn-bandy-urbag commented on GitHub (May 1, 2020):

It's been a minute but I believe I moved to postgres rather than sqlite as a backend. But I may have moved on to another solution altogether. Hope this helps. Don't hold me to it, though.

@shawn-bandy-urbag commented on GitHub (May 1, 2020): It's been a minute but I believe I moved to postgres rather than sqlite as a backend. But I may have moved on to another solution altogether. Hope this helps. Don't hold me to it, though.

GiteaMirror commented

2025-11-02 05:11:25 -06:00

@framuc commented on GitHub (May 6, 2020):

It's been a minute but I believe I moved to postgres rather than sqlite as a backend. But I may have moved on to another solution altogether. Hope this helps. Don't hold me to it, though.

Unfortunately it didn't work for me, but thank you anyway.

@framuc commented on GitHub (May 6, 2020): > > > It's been a minute but I believe I moved to postgres rather than sqlite as a backend. But I may have moved on to another solution altogether. Hope this helps. Don't hold me to it, though. Unfortunately it didn't work for me, but thank you anyway.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3390