"SQLITE_BUSY: database is locked" error appears in Azure self-hosted environment

Questions
1

Describe the problem/error/question

I’ve deployed an Azure Container App running the latest n8nio/n8n image. I also created a Storage Account with a File Share to persist the database.sqlite file between container restarts.

When I run the app without mounting the file share, the app starts successfully — but all data is lost after a restart, as expected.

However, when I mount the Azure File Share and point N8N to use /n8npoctestfileshare/.n8n/database.sqlite as the database path, the container fails with the following error: SQLITE_BUSY: database is locked.

I’ve verified that:

  • The file share is mounted correctly
  • The folder /n8npoctestfileshare/.n8n/ and the file database.sqlite do get created
  • No other container or process is accessing this database file

What could be causing the locked database issue when using Azure File Share, even on first startup? Is there a known limitation or special handling required when using SQLite with mounted CIFS volumes in this context?

Environment Variables in Use:
- GENERIC_TIMEZONE: Etc/UTC
- TRUST_PROXY: true
- N8N_BASIC_AUTH: true
- N8N_BASIC_AUTH_USER: *user*
- N8N_BASIC_AUTH_PASSWORD: *pass*
- WEBHOOK_URL: *container_app_url*
- EXECUTIONS_PROCESS: main
- DB_SQLITE_POOL_SIZE: 1
- N8N_USER_FOLDER: /n8npoctestfileshare
- DB_SQLITE_DATABASE: /n8npoctestfileshare/.n8n/database.sqlite
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: false

What is the error message (if any)?

“SQLITE_BUSY: database is locked”

Logs (from most recent):

  • Last session crashed
  • There was an error initializing DB
  • SQLITE_BUSY: database is locked
  • User settings loaded from: /n8npoctestfileshare/.n8n/config
    Permissions 0777 for n8n settings file /n8npoctestfileshare/.n8n/config are too wide. This is ignored for now, but in the future n8n will attempt to change the permissions automatically. To automatically enforce correct permissions now set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true (recommended), or turn this check off set N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.
  • Initializing n8n process

Please share your workflow

No workflow can be created yet.

Information on your n8n setup

  • n8n version: Current n8nio/n8n:latest Docker image (I believe it’s v1.100.1)
  • Database: SQLite
  • n8n EXECUTIONS_PROCESS setting: main
  • Running n8n via: Azure Container App (using Docker Hub image)
2

I don’t know if it will help or not. But try to add EXECUTIONS_PROCESS: queue to your yaml environment.

And lemme know if it works.

3

Unfortunately, no changes

4

I have no more idea…
sorry…

5

Hi Dana,

You should try to use the mount option “nobrl” in the mount option of your SMB Volume.
See there : Recommended and useful mountOptions settings on Azure Files - Azure | Microsoft Learn

N8N
N8N506×423 38.9 KB

1 Like
6

Same thing is happening to me, identical setup. I did try the “nobrl” option for the storage mount but that didn’t change anything. I also made sure that there was only one revision and one replica running, but this seems totally broken. It worked fine when I ran the same (latest) n8n image in Docker Desktop. I also tried initializing n8n in Docker Desktop and copying the database.sqlite file up to the Azure storage account, but that yielded the same error.

7

Hi, I saw the same issue with a new dev instance. The SQLLite DB is probably locked by another revision of your container app. Stopping the container app completely and then starting it again ensures only 1 revision is running and the DB migrations can complete. Worked for me anyway :slight_smile:

8

In Azure, a local sqlite database deported in a file share does not work, even with a single replica. Use a flexible postgresql database instead.

9

That actually worked very well. Thanks!