We could not log you in - contact an admin. [002] Failed to authenticate Try Again →

[MAS-CreativeLabs]

Hello Everyone,

I hope this message finds you well.

I'm currently facing a challenge with an issue that was previously discussed here.

I tried the solution previously listed

SYS_EMAIL="root@vectoradmin.com"
SYS_PASSWORD="password"

I also tried with hunter2

but it didn't work how did you guys get it to work?

I'm reaching out to inquire if anyone else has encountered a similar problem and, if so, how you managed to overcome it. Any insights or guidance would be greatly appreciated, as I'm keen on understanding the root cause and finding a viable solution.

Thank you for your time and assistance.

[timothycarambat]

• [ ] Ensure you have a database connected to the container via the DATABASE_URL environment variable and the connection string is correct
• [ ] On boot of the container the default credentials will be created which are root@vectoradmin.com and password unless otherwise defined on container start https://github.com/Mintplex-Labs/vector-admin/blob/6cad8a30a1a89f645e02e0663ccf8832dfe87047/backend/utils/boot/index.js#L51-L52

[MAS-CreativeLabs]

Where do I set the DATABASE_URL environment variable? Should I add it to the .env file? What is the expected value for the variable?

[MAS-CreativeLabs]

Here's my docker-compose.yml:

version: "3.9"
services:
  db:
    image: postgres
    container_name: vectoradmin-db
    hostname: vectoradmin-db
    mem_limit: 1g
    cpu_shares: 768
    ports:
      - 5433:5432
    networks:
      - vector-admin_default
    security_opt:
      - no-new-privileges:true
    user: 1026:100
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "vdbms", "-U", "vectoradminuser"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
      - /volume1/docker/projects/vectoradmin/db:/var/lib/postgresql/data:rw
    environment:
      TZ: America/Los_Angeles
      POSTGRES_DB: vdbms
      POSTGRES_USER: vectoradminuser
      POSTGRES_PASSWORD: vectoradminpass
    restart: on-failure:5

  vectoradmin:
    image: mintplexlabs/vectoradmin:master
    container_name: vector-admin
    hostname: vector-admin
    mem_limit: 2g
    cpu_shares: 768
    ports:
      - 4950:3001
    networks:
      - vector-admin_default
    extra_hosts:
      - host.docker.internal:host-gateway
    cap_add:
      - SYS_ADMIN
    volumes:
      - /volume1/docker/projects/vectoradmin:/app/backend/storage
      - /volume1/docker/projects/vectoradmin/.env:/app/backend/.env
    environment:
      SERVER_PORT: 3001
      DISABLE_TELEMETRY: true
      TZ: America/Los_Angeles
      JWT_SECRET: secret
      SYS_EMAIL: root@vectoradmin.com
      SYS_PASSWORD: password
      INNGEST_EVENT_KEY: background_workers
      INNGEST_SIGNING_KEY: secret
      INNGEST_LANDING_PAGE: true
      DATABASE_CONNECTION_STRING: postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms     
    depends_on:
      db:
        condition: service_healthy

networks:
  vector-admin_default:
    driver: bridge
    external: true

Here's my .env:

SERVER_PORT="3001"
DISABLE_TELEMETRY="true"
TZ="America/Los_Angeles"
JWT_SECRET="secret"
SYS_EMAIL="root@vectoradmin.com"
SYS_PASSWORD="password"
INNGEST_EVENT_KEY="background_workers"
INNGEST_SIGNING_KEY="secret"
INNGEST_LANDING_PAGE="true"
DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms"

Should I still add DATABASE_URL to the .env file? Wouldn't that be redundant with:

DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms"

[timothycarambat]

It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists.

Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go.

[MAS-CreativeLabs]

It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists.

Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go.

Thank you @timothycarambat

• I am pulling from docker hub:

image: mintplexlabs/vectoradmin:master

• Using the following credentials to start:

  SYS_EMAIL="root@vectoradmin.com"
  SYS_PASSWORD="password"

I am seeing nothing worth noting in my logs (no error). I can provide the logs if you need them. Can you tell me if you saw something wrong with my docker-compose.yml and .env files?

[timothycarambat]

When you attempt to login can you open the Network tab in the browser inspector window and confirm the URL that the login request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind 4950:3001 it may still be attempting to send a request to :3001 from the frontend

[MAS-CreativeLabs]

When you attempt to login can you open the Network tab in the browser inspector window and confirm the URL that the login request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind 4950:3001 it may still be attempting to send a request to :3001 from the frontend

Wow!!! that's a great explanation I'm going to try to bind with 3001:3001

However, if this solves the problem I'd have to stop anything-llm in other to use vector-admin it's a shame since it's the same company that created both docker images 🤔 ... that would have been great if the two configurations weren't in conflict with each other 😅

[MAS-CreativeLabs]

I get the same issue after changing the port to 3001:3001

Here's the log for vector-admin container after the boot:

2024-01-01T00:14:03.872288061Z Environment variables loaded from .env
2024-01-01T00:14:03.873460511Z Prisma schema loaded from prisma/schema.prisma
2024-01-01T00:14:03.882096499Z Datasource "db": PostgreSQL database "vdbms", schema "public" at "vectoradmin-db:5432"
2024-01-01T00:14:04.072120309Z 
2024-01-01T00:14:04.072267100Z 4 migrations found in prisma/migrations
2024-01-01T00:14:04.072349031Z 
2024-01-01T00:14:04.216328096Z 
2024-01-01T00:14:04.216453807Z No pending migrations to apply.
2024-01-01T00:14:04.257778079Z npm notice 
2024-01-01T00:14:04.258223773Z npm notice New patch version of npm available! 10.2.3 -> 10.2.5
2024-01-01T00:14:04.258454945Z npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.5>
2024-01-01T00:14:04.258947379Z npm notice Run `npm install -g npm@10.2.5` to update!
2024-01-01T00:14:04.259206372Z npm notice 
2024-01-01T00:14:05.882839738Z Environment variables loaded from .env
2024-01-01T00:14:05.883903297Z Prisma schema loaded from prisma/schema.prisma
2024-01-01T00:14:06.923357768Z 
2024-01-01T00:14:06.923838333Z ✔ Generated Prisma Client (v5.3.1) to ./node_modules/@prisma/client in 380ms
2024-01-01T00:14:06.923935284Z 
2024-01-01T00:14:06.923973464Z Start using Prisma Client in Node.js (See: https://pris.ly/d/client)
2024-01-01T00:14:06.924027164Z ```
2024-01-01T00:14:06.924075925Z import { PrismaClient } from '@prisma/client'
2024-01-01T00:14:06.924131665Z const prisma = new PrismaClient()
2024-01-01T00:14:06.924181456Z ```
2024-01-01T00:14:06.924225026Z or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
2024-01-01T00:14:06.924281937Z ```
2024-01-01T00:14:06.924323717Z import { PrismaClient } from '@prisma/client/edge'
2024-01-01T00:14:06.924356367Z const prisma = new PrismaClient()
2024-01-01T00:14:06.924399148Z ```
2024-01-01T00:14:06.924443268Z 
2024-01-01T00:14:06.924482269Z See other ways of importing Prisma Client: http://pris.ly/d/importing-client
2024-01-01T00:14:06.924554869Z 
2024-01-01T00:14:06.962704212Z ┌─────────────────────────────────────────────────────────┐
2024-01-01T00:14:06.962861654Z │  Update available 5.3.1 -> 5.7.1                        │
2024-01-01T00:14:06.962937834Z │  Run the following to update                            │
2024-01-01T00:14:06.963002935Z │    npm i --save-dev prisma@latest                       │
2024-01-01T00:14:06.963065816Z │    npm i @prisma/client@latest                          │
2024-01-01T00:14:06.963128096Z └─────────────────────────────────────────────────────────┘
2024-01-01T00:14:07.505098122Z yarn run v1.22.19
2024-01-01T00:14:07.570884484Z $ /app/workers/node_modules/.bin/inngest-cli dev -u http://0.0.0.0:3355/background-workers
2024-01-01T00:14:07.649376050Z [2023-12-31 16:14:07 -0800] [106] [INFO] Starting gunicorn 20.1.0
2024-01-01T00:14:07.655372934Z [2023-12-31 16:14:07 -0800] [106] [INFO] Listening at: http://0.0.0.0:8888 (106)
2024-01-01T00:14:07.655585596Z [2023-12-31 16:14:07 -0800] [106] [INFO] Using worker: sync
2024-01-01T00:14:07.709884914Z [2023-12-31 16:14:07 -0800] [157] [INFO] Booting worker with pid: 157
2024-01-01T00:14:07.793942250Z [2023-12-31 16:14:07 -0800] [158] [INFO] Booting worker with pid: 158
2024-01-01T00:14:07.839947094Z [2023-12-31 16:14:07 -0800] [160] [INFO] Booting worker with pid: 160
2024-01-01T00:14:07.899226477Z [2023-12-31 16:14:07 -0800] [166] [INFO] Booting worker with pid: 166
2024-01-01T00:14:07.948010376Z setupFunctions failed fetch failed
2024-01-01T00:14:08.057188618Z 2023-12-31T16:14:08-08:00 INF runner > starting event stream | backend=redis
2024-01-01T00:14:08.057343510Z 2023-12-31T16:14:08-08:00 INF runner > service starting 
2024-01-01T00:14:08.057625952Z 2023-12-31T16:14:08-08:00 INF runner > subscribing to events | topic=events
2024-01-01T00:14:08.059844332Z 2023-12-31T16:14:08-08:00 INF devserver > autodiscovering locally hosted SDKs 
2024-01-01T00:14:08.063313114Z 2023-12-31T16:14:08-08:00 INF devserver > service starting 
2024-01-01T00:14:08.063537606Z 2023-12-31T16:14:08-08:00 INF api > starting server | addr=0.0.0.0:8288
2024-01-01T00:14:08.063726627Z 2023-12-31T16:14:08-08:00 INF executor > service starting 
2024-01-01T00:14:08.063806188Z 2023-12-31T16:14:08-08:00 INF executor > subscribing to function queue 
2024-01-01T00:14:08.386400080Z Storage folder for vector-cache created.
2024-01-01T00:14:08.387288698Z [TELEMETRY DISABLED] Telemetry is marked as disabled - no events will send. Telemetry helps Mintplex Labs Inc improve VectorAdmin.
2024-01-01T00:14:08.414470663Z prisma:info Starting a postgresql pool with 9 connections.
2024-01-01T00:14:08.720617237Z prisma:query SELECT COUNT(*) FROM (SELECT "public"."users"."id" FROM "public"."users" WHERE "public"."users"."role" = $1 OFFSET $2) AS "sub"
2024-01-01T00:14:08.720788478Z prisma:query SELECT "public"."users"."id", "public"."users"."email", "public"."users"."password", "public"."users"."role", "public"."users"."createdAt", "public"."users"."lastUpdatedAt" FROM "public"."users" WHERE ("public"."users"."email" = $1 AND "public"."users"."role" = $2) LIMIT $3 OFFSET $4
2024-01-01T00:14:08.797828401Z Example app listening on port 3001
2024-01-01T00:14:08.803516322Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3
2024-01-01T00:14:08.820855458Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt"
2024-01-01T00:14:08.828308145Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3
2024-01-01T00:14:08.858549358Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt"
2024-01-01T00:14:09.511826204Z Warning: connect.session() MemoryStore is not
2024-01-01T00:14:09.512325949Z designed for a production environment, as it will leak
2024-01-01T00:14:09.512431810Z memory, and will not scale past a single process.
2024-01-01T00:14:09.957219191Z setupFunctions success! 200
2024-01-01T00:14:09.957536134Z Background workers listening on port 3355
2024-01-01T00:14:09.957747966Z [Developer Notice] Run npx inngest-cli@latest dev -u http://127.0.0.1:3355/background-workers to debug events for workers or visit http://127.0.0.1:3355/background-workers

[MAS-CreativeLabs]

here's logs from vectoradmin-db (postgresql database) container:

chmod: changing permissions of '/var/run/postgresql': Operation not permitted
PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-12-31 16:35:57.647 PST [1] LOG:  starting PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2023-12-31 16:35:57.648 PST [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-12-31 16:35:57.648 PST [1] LOG:  listening on IPv6 address "::", port 5432
2023-12-31 16:35:57.671 PST [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-12-31 16:35:57.780 PST [16] LOG:  database system was shut down at 2023-12-31 16:35:51 PST
2023-12-31 16:35:57.830 PST [1] LOG:  database system is ready to accept connections

[MAS-CreativeLabs]

[timothycarambat]

so the Err_CONNECTION_REFUSED is meaning that the backend does not appear to be reachable by the frontend. If you visit http://127.0.0.1:3001/api/ping do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict

[JairajGaur]

I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck.

[MAS-CreativeLabs]

I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck.

hey @JairajGaur what do you mean by "multiple cleanup of docker images"?

[MAS-CreativeLabs]

so the Err_CONNECTION_REFUSED is meaning that the backend does not appear to be reachable by the frontend. If you visit http://127.0.0.1:3001/api/ping do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict

@timothycarambat thanks for your response, and happy new year! when you say visiting http://127.0.0.1:3001/api/ping for that test, should I be on the docker container when trying to reach the address? because so far I'm trying via another machine on the same network

[timothycarambat]

However you would normally use the interface, so in this case http://<machine.ip>:3001/api/ping.

When you shared the screenshot of the frontend sending a request to http://127.0.0.1:3001/api/login were you on another machine totally? Because then it would make sense that http://127.0.0.1:3001 did not work, since the machine you were on is not running VectorAdmin! That would be a critical detail to know. I made the assumption you were running VectorAdmin on the same machine you would access it on.

[felixstander]

@timothycarambat I'm also facing the same problem. The server is up on a remote machine through the docker image, and i'm able to get back "OK" info after sending a request to http://:3001/api/ping on my local machine. I check Network tab in the browser inspector window when attempting to login, and the error is the same as @MAS-CreativeLabs provides.

[timothycarambat]

Will mark this as a bug for now, but I think the issue is that the docker image is running on a localmachine and the VITE_API_BASE is assuming localhost where is could be changed to be relative so the root URL can be assumed from the client side, enabling docker image on remote IPs

https://github.com/Mintplex-Labs/vector-admin/blob/e7659c94476cb3329cb3ade9f5a49cc9915d99d3/frontend/src/utils/constants.ts#L2

[felixstander]

@timothycarambat thanks for the reply, how can I change the VITE_API_BASE from the pre-built image?

[felixstander]

@timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself.

[MAS-CreativeLabs]

@timothycarambat can we get to a solution that does not involve rebuilding the image each time you update your code? I don't want to fork the repo or rebuild an image just for an IP address. Can you set the address to the hostname of the DB?

[MAS-CreativeLabs]

Or maybe make it an environmental variable that we could set via the docker-compose.yml or .env

[MAS-CreativeLabs]

@timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself.

@felixstander how did you change the VITE_API_BASE from the pre-built image?

[felixstander]

@MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building.

[MAS-CreativeLabs]

@MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building.

@felixstander In the frontend folder I only have .env.example containing the following lines:

VITE_APP_NAME="VectorAdmin"
# VITE_API_BASE='/api' # Use this URL deploying on non-localhost address.

is this the file you're referring to? what did you put in the file? How long did it take to rebuild? I'm also curious about your thoughts about the workflow do you think it's a viable solution? I find this workflow to be odd, having to rebuild an image after each commit is hard to maintain in a testing environment much less for production

I think just having a variable in the .env with the prebuilt image would help users tremendously

[timothycarambat]

Just updated the image and build, and the VITE_API_BASE to now be relative. When the build is complete and is published you should be able to pull in the new image and it should function on local and remote IPs as the VITE_API_BASE will be relative.

https://github.com/Mintplex-Labs/vector-admin/actions/runs/7470209197/job/20328530326

[MAS-CreativeLabs]

@timothycarambat Thank you it worked! ✅

[MAS-CreativeLabs]

Now the new issue is the following: I'm getting fetch Failed The URL my chroma instance is reachable at is http://10.255.255.254:5959

I try the following: http://10.255.255.254:5959 ❌ http://10.255.255.254:5959/api/v1 ❌ http://10.255.255.254:5959/api/v1/ ❌

Idon't think it my chromadb install that's at fault here because it works with flowise and anything-llm.

• [ ] http://10.255.255.254:5959/api/v1/heartbeat returns the following:

{"nanosecond heartbeat":1705027265899832507}

• [ ] http://10.255.255.254:5959/api/v1/collections returns the following:

[{"name":"valhala","id":"828f1797-6636-4a76-878f-a0c24936d1cd","metadata":{"hnsw:space":"cosine"},"tenant":"default_tenant","database":"default_database"},{"name":"flowise","id":"97abe11a-760e-4ce1-8b1a-9b3004fd114c","metadata":null,"tenant":"default_tenant","database":"default_database"}]

[MAS-CreativeLabs]

Never mind, I fix it. oddly it works behind my reverse proxy with https 😅