Error Initializing DB: "relation "shared_workflow" does not exist"

Describe the issue/error/question

When starting up an instance of 0.168.0 (user management enabled) or later, the initialization process fails with a database error. Initially we thought this might be due to the fact that we’re using a database used with previous versions, but unfortunately we get the same error with a brand new database.

What is the error message (if any)?

Attaching to ubuntu_n8n_1
n8n_1  | 2022-03-21T15:44:53.027Z | info     | Initializing n8n process {"file":"start.js"}
n8n_1  | UserSettings were generated and saved to: /home/node/.n8n/config
n8n_1  | 2022-03-21T15:44:55.067Z | debug    | No codex available for: KoBoToolbox.node.js {"file":"LoadNodesAndCredentials.js","function":"addCodex"}
n8n_1  | 2022-03-21T15:44:55.070Z | debug    | No codex available for: KoBoToolboxTrigger.node.js {"file":"LoadNodesAndCredentials.js","function":"addCodex"}
n8n_1  | 2022-03-21T15:44:55.086Z | debug    | No codex available for: Linear.node.js {"file":"LoadNodesAndCredentials.js","function":"addCodex"}
n8n_1  | 2022-03-21T15:44:56.033Z | debug    | No codex available for: N8nTrainingCustomerDatastore.node.js {"file":"LoadNodesAndCredentials.js","function":"addCodex"}
n8n_1  | 2022-03-21T15:44:56.034Z | debug    | No codex available for: N8nTrainingCustomerMessenger.node.js {"file":"LoadNodesAndCredentials.js","function":"addCodex"}
n8n_1  | 2022-03-21T15:44:58.598Z | error    | There was an error initializing DB: "relation "shared_workflow" does not exist" {"file":"start.js"}
n8n_1  | 2022-03-21T15:44:58.599Z | info     |
n8n_1  | Stopping n8n... {"file":"start.js","function":"stopProcess"}

Information on your n8n setup

  • n8n version: 0.169.0 (have tried 0.168.0, 0.168.1 as well)
  • Database you’re using (default: SQLite): Postgres 11.4, and 13.3
  • Running n8n with the execution process [own(default), main]: Own? Not sure…
  • Running n8n via [Docker, npm,, desktop app]: Docker

Docker-compose File

version: "3"
    image: n8nio/n8n:0.169.0-debian
    restart: always
      - "80:80"
      - N8N_ENCRYPTION_KEY=<protected>
      - N8N_HOST=<protected>
      - N8N_EDITOR_BASE_URL=<protected>
      - N8N_PORT=80
      - N8N_PROTOCOL=http
      - NODE_ENV=production
      - WEBHOOK_TUNNEL_URL=<protected>
      - VUE_APP_URL_BASE_API=<protected>
      - DB_TYPE=postgresdb
      - DB_TABLE_PREFIX=UM_user_
      - DB_POSTGRESDB_HOST=<protected>
      - DB_POSTGRESDB_USER=<protected>
      - DB_POSTGRESDB_PASSWORD=<protected>
      - DB_POSTGRESDB_SSL_CA_FILE=/etc/ssl/root.crt
      - N8N_LOG_LEVEL=debug
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/ssl/root.crt:/etc/ssl/root.crt

Please let me know if you need any other information from me to help diagnose this issue. Thank you!

Sorry for the false alarm, we were running multiple instances of n8n connected to the same Postgres database so we required use of the DB_TABLE_PREFIX environment variable. Now that user management allows multiple people on the same instance we no longer needed the environment variable, and removing it fixed the issue. Apologies if this was clarified somewhere. Thanks!

1 Like

Hey @Ian_Taggart,

That is good news, I was about to hit the panic button :slight_smile:

1 Like

Sorry to open this back up, but quick question @Jon - are there any other environment variables we are using that are now redundant with user management? Curious about N8N_ENCRYPTION_KEY and how it comes into play with user management… If we plan on redeploying a new container of n8n every so often (30-60 days) with no encryption key defined, I’m assuming it’ll create a new one on start-up - at that point, will we be locked out of some encrypted functionality on the database side since there’s a new encryption key? Thanks for any insight you can provide.

Hey @Ian_Taggart,

With user management the only keys not needed is the basic Auth and user / password options. The encryption key is what gets used to encrypt the node credentials in the database so if you were moving credentials / sharing a database with worker instances you would need that key to be set so they can read them.

1 Like