grimoire icon indicating copy to clipboard operation
grimoire copied to clipboard

SQLiteError: no such table: user

Open tehniemer opened this issue 1 year ago • 3 comments

Followed the docker install instructions and was presented with the following error when trying to access the service.

SQLiteError: no such table: user

1
      at prepare (bun:sqlite:280:10)
      at prepareQuery (/app/node_modules/drizzle-orm/bun-sqlite/session.js:20:30)
      at _prepare (/app/node_modules/drizzle-orm/sqlite-core/query-builders/select.js:572:73)
      at all (/app/node_modules/drizzle-orm/sqlite-core/query-builders/select.js:588:17)
      at execute (/app/node_modules/drizzle-orm/sqlite-core/query-builders/select.js:596:19)
      at then (/app/node_modules/drizzle-orm/query-promise.js:21:17)
15 |   logger;
16 |   exec(query) {
17 |     this.client.exec(query);
18 |   }
19 |   prepareQuery(query, fields, executeMethod, isResponseInArrayMode, customResultMapper) {
20 |     const stmt = this.client.prepare(query.sql);

Here's my compose snippet

services:
  grimoire:
    image: goniszewski/grimoire:develop
    build:
      context: .
      dockerfile: Dockerfile
    container_name: grimoire
    restart: unless-stopped
    networks:
      - traefik
    ports:
      - $GRIMOIRE_PORT:5173
    security_opt:
      - no-new-privileges=true
    logging:
      options:
        max-size: 2m
        max-file: "3"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/docker/grimoire:/app/data/
    environment:
      - PORT=5173
      - PUBLIC_HTTPS_ONLY=false
      - PUBLIC_SIGNUP_DISABLED=false
    labels:
      - homepage.group=Containers
      - homepage.name=Grimoire
      - homepage.icon=grimoire
      - homepage.description=Bookmark Management
      - homepage.href=https://grimoire.$DOMAINNAME
      - homepage.siteMonitor=http://$HOST:$GRIMOIRE_PORT
      - traefik.enable=true
      - traefik.http.routers.grimoire-rtr.entrypoints=https
      - traefik.http.routers.grimoire-rtr.rule=Host(`grimoire.$DOMAINNAME`)
      - traefik.http.routers.grimoire-rtr.middlewares=chain-no-auth@file # No Authentication
      - traefik.http.routers.grimoire-rtr.service=grimoire-svc
      - traefik.http.services.grimoire-svc.loadbalancer.server.port=5173

tehniemer avatar Sep 28 '24 01:09 tehniemer

Hello @tehniemer!

Could you try to set up the app again using the latest tag for the Docker image (develop may be missing some latest hotfixes)?

Also, make sure to remove existing Docker volume used by Grimoire and allow it to create a new one.

goniszewski avatar Sep 28 '24 08:09 goniszewski

Sure thing, after removing the existing mountpoint and changing to the latest tag I get the following errors

$ bun run ./migrate
1 | import { Database } from 'bun:sqlite';
2 | import { drizzle } from 'drizzle-orm/bun-sqlite';
3 | import { migrate } from 'drizzle-orm/bun-sqlite/migrator';
4 | 
5 | const sqlite = new Database('data/db.sqlite');
                   ^
SQLiteError: unable to open database file
 errno: 14
  code: "SQLITE_CANTOPEN"
      at new Database (bun:sqlite:178:14)
      at /app/migrate.js:5:16
Bun v1.1.29 (Linux x64 baseline)
error: script "run-migrations" exited with code 1
$ bun run ./migrate
1 | import { Database } from 'bun:sqlite';
2 | import { drizzle } from 'drizzle-orm/bun-sqlite';
3 | import { migrate } from 'drizzle-orm/bun-sqlite/migrator';
4 | 
5 | const sqlite = new Database('data/db.sqlite');
                   ^

Maybe a permissions issue with the bind mount? What UID and GID does the container run?

tehniemer avatar Sep 28 '24 13:09 tehniemer

I've tried to reproduce your issue, but unsuccessfully. For the permissions used, please check this line in the Dockerfile: https://github.com/goniszewski/grimoire/blob/main/Dockerfile#L11

goniszewski avatar Sep 28 '24 14:09 goniszewski

same issue here

victornavorskie avatar Oct 11 '24 12:10 victornavorskie

same, doesn't work for me either

DavidDotCheck avatar Oct 13 '24 10:10 DavidDotCheck

Something fun that I noticed is that running adduser --disabled-password --gecos '' grimoire and mkdir -p /app/data && chown -R grimoire:grimoire /app/data && chmod 755 /app/data inside the container, then switching the tag to latest fixes both issues:

$ sudo rm -rf /etc/grimoire/data/
$ sudo nano /etc/grimoire/docker-compose.yml 
$ sudo docker-compose up -d
WARNING: The PORT variable is not set. Defaulting to a blank string.
Creating grimoire ... done
$docker exec -it 43f8aa47b259 bash
root@43f8aa47b259:/app# mkdir -p /app/data && chown -R grimoire:grimoire /app/data && chmod 755 /app/data
chown: invalid user: 'grimoire:grimoire'
root@43f8aa47b259:/app# adduser --disabled-password --gecos '' grimoire
Adding user `grimoire' ...
Adding new group `grimoire' (1001) ...
Adding new user `grimoire' (1001) with group `grimoire' ...
Creating home directory `/home/grimoire' ...
Copying files from `/etc/skel' ...
root@43f8aa47b259:/app# mkdir -p /app/data && chown -R grimoire:grimoire /app/data && chmod 755 /app/data
root@43f8aa47b259:/app# exit
exit
$ sudo docker-compose down
WARNING: The PORT variable is not set. Defaulting to a blank string.
Stopping grimoire ... 
^CERROR: Aborting.
$  docker rm -f $ID
43f8aa47b259
$ sudo nano /etc/grimoire/docker-compose.yml 
$ sudo docker-compose up -d
WARNING: The PORT variable is not set. Defaulting to a blank string.
Creating grimoire ... done

Just doing docker-compose up after running the commands doesn't fix the issue because now the user table doesn't exist.

DavidDotCheck avatar Oct 13 '24 11:10 DavidDotCheck

I've found an interesting thing. Using a directory mount causes the error.

# This doesn't work
volumes:
  - ./data:/app/data

Removing volumes makes the app start, as well as using Docker volume.

# This works
# volumes
#   -./data:/app/data
# This works
volumes:
  grimoire_data:/app/data

AnonymousX86 avatar Oct 18 '24 02:10 AnonymousX86

That usually means it's a directory permission issue. If the container doesn't run as root or chown the directory after creation this tends to happen.

I've removed this from my stack so I'm not able to test this.

tehniemer avatar Oct 18 '24 02:10 tehniemer

I may have introduced some unnecessary permission changes in the latest update to Dockerfile. Sorry for that, I will look into this in the next days.

goniszewski avatar Oct 23 '24 18:10 goniszewski

Best would be to make use of PUID and PGID.

AnonymousX86 avatar Oct 24 '24 13:10 AnonymousX86

image

same issue with unraid.

Roalkege avatar Nov 12 '24 16:11 Roalkege

Possible fix for this issue is now being released under the preview tag of the Docker image: https://github.com/goniszewski/grimoire/actions/runs/11844872252

Please let me know if it's still not working!

goniszewski avatar Nov 14 '24 20:11 goniszewski

For me, this does not work. I deleted the grimore folder. After that, I started the preview image and it crashed.

docker logs 04be30ff4850
chown: changing ownership of '/app/data': Operation not permitted
chmod: changing permissions of '/app/data': Operation not permitted
$ bun run ./migrate
1 | import { Database } from 'bun:sqlite';
2 | import { drizzle } from 'drizzle-orm/bun-sqlite';
3 | import { migrate } from 'drizzle-orm/bun-sqlite/migrator';
4 | 
5 | const sqlite = new Database('data/db.sqlite');
                   ^
SQLiteError: unable to open database file
 errno: 14
  code: "SQLITE_CANTOPEN"

      at new Database (bun:sqlite:195:14)
      at /app/migrate.js:5:16

Bun v1.1.34 (Linux x64 baseline)
error: script "run-migrations" exited with code 1

Roalkege avatar Nov 15 '24 05:11 Roalkege

@goniszewski I saw your call for help on Reddit and figured you were having the exact same problem as I had in PlexRipper namely https://github.com/PlexRipper/PlexRipper/issues/208.

I had the same permission issues and resolved it by converting my dockerfile to use s6-overlay, which supports: PUID and PGID. This is exactly what LinuxServer.io uses for all their images and resolves permission issues.

Read a bit through the links and let me know if you have any questions!

JasonLandbridge avatar Nov 15 '24 12:11 JasonLandbridge

Thanks, @JasonLandbridge, I will check it!

goniszewski avatar Nov 16 '24 11:11 goniszewski

Any news?

Roalkege avatar Dec 17 '24 07:12 Roalkege

After some time tinkering, I may have found a solution for this problem. Please check those changes: https://github.com/goniszewski/grimoire/pull/162/files

goniszewski avatar Dec 17 '24 21:12 goniszewski

same issue with unraid.

As with many containers on Unraid (and elsewhere/containers in general), using Docker’s --user flag often resolves file permission issues by mapping the container process to a specific user and group which has permissions to the storage location. On Unraid, set UID=99 (nobody) and GID=100 (users). Example:

# On Unraid set this using the post arguments field of template: `--user 99:100`
docker run --user 99:100 -v /path/to/data:/app/data goniszewski/grimoire:latest  # replace 99:100 with user/group that has permissions to path
# Or with docker compose
    ...
    image: goniszewski/grimoire:latest
    user: "99:100"
    volumes:
      - /path/to/data:/app/data
        ...

If the container supports PUID/PGID, you can also set these environment variables to achieve the same result. However, Grimoire doesn’t support PUID/PGID, so the --user method was the fix here.

The changes introduced by goniszewski in #162 should also help, but if issues persist, double-check your file permissions and try this approach.

cw-cdz avatar Dec 19 '24 12:12 cw-cdz

As with many containers on Unraid (and elsewhere/containers in general), using Docker’s --user flag often resolves file permission issues by mapping the container process to a specific user and group which has permissions to the storage location. On Unraid, set UID=99 (nobody) and GID=100 (users). Example:

I added the --user 99:100 the the args...

docker run
  -d
  --name='grimoire'
  --net='bridge'
  --pids-limit 2048
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="unRaid"
  -e HOST_CONTAINERNAME="grimoire"
  -e 'PUBLIC_HTTPS_ONLY'='false'
  -e 'PUBLIC_SIGNUP_DISABLED'='false'
  -e 'PORT'='5173'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:5173]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/A75G/docker-templates/master/templates/icons/grimoire.png'
  -p '5173:5173/tcp'
  -v '/mnt/user/appdata/grimoire/':'/app/data/':'rw'
  --user 99:100 'goniszewski/grimoire:latest'

But still the SQLiteError: unable to open database file error.

Roalkege avatar Dec 19 '24 12:12 Roalkege

As with many containers on Unraid (and elsewhere/containers in general), using Docker’s --user flag often resolves file permission issues by mapping the container process to a specific user and group which has permissions to the storage location. On Unraid, set UID=99 (nobody) and GID=100 (users). Example:

I added the --user 99:100 the the args...

docker run
  -d
  --name='grimoire'
  --net='bridge'
  --pids-limit 2048
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="unRaid"
  -e HOST_CONTAINERNAME="grimoire"
  -e 'PUBLIC_HTTPS_ONLY'='false'
  -e 'PUBLIC_SIGNUP_DISABLED'='false'
  -e 'PORT'='5173'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:5173]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/A75G/docker-templates/master/templates/icons/grimoire.png'
  -p '5173:5173/tcp'
  -v '/mnt/user/appdata/grimoire/':'/app/data/':'rw'
  --user 99:100 'goniszewski/grimoire:latest'

But still the SQLiteError: unable to open database file error.

Did you verify the permissions and owner on the container folder in appdata location? They would have been created previously using incorrect. Either adjust them or delete everything and let them be recreated. I would still suggest checking them after they are recreated.

The key idea here is the storage location is not accessible or writable by the container process.

cw-cdz avatar Dec 20 '24 19:12 cw-cdz

Did you verify the permissions and owner on the container folder in appdata location? They would have been created previously using incorrect. Either adjust them or delete everything and let them be recreated. I would still suggest checking them after they are recreated.

The key idea here is the storage location is not accessible or writable by the container process.

I had to set it manually to nobody.

Roalkege avatar Dec 23 '24 21:12 Roalkege

I'm having the same issue, I tried the latest preview, 0.4, 0.4.4 and all gave the same error.

Got it running on 0.3

LukanRocks avatar Jan 10 '25 02:01 LukanRocks

What is the status with this? Using a bind mount is not working and I don't want to use volumes.

`Bun v1.1.34 (Linux x64 baseline) error: script "run-migrations" exited with code 1 chown: changing ownership of '/app/data': Operation not permitted chmod: changing permissions of '/app/data': Operation not permitted $ bun run ./migrate 1 | import { Database } from 'bun:sqlite'; 2 | import { drizzle } from 'drizzle-orm/bun-sqlite'; 3 | import { migrate } from 'drizzle-orm/bun-sqlite/migrator'; 4 | 5 | const sqlite = new Database('data/db.sqlite'); ^ SQLiteError: unable to open database file errno: 14 code: "SQLITE_CANTOPEN"

  at new Database (bun:sqlite:195:14)
  at /app/migrate.js:5:16

Bun v1.1.34 (Linux x64 baseline) error: script "run-migrations" exited with code 1`

using both :latest and :preview

joshoram80 avatar Jan 13 '25 22:01 joshoram80

Adding:

user: root

Fixes the issue. This is weird, as according to docs the container should run as root by default.

volumes:
  - ./data:/app/data

New folder is owned by root:1001.

AnonymousX86 avatar Jan 19 '25 19:01 AnonymousX86

same issue with unraid.

As with many containers on Unraid (and elsewhere/containers in general), using Docker’s --user flag often resolves file permission issues by mapping the container process to a specific user and group which has permissions to the storage location. On Unraid, set UID=99 (nobody) and GID=100 (users). Example:

On Unraid set this using the post arguments field of template: --user 99:100

docker run --user 99:100 -v /path/to/data:/app/data goniszewski/grimoire:latest # replace 99:100 with user/group that has permissions to path

Or with docker compose

...
image: goniszewski/grimoire:latest
user: "99:100"
volumes:
  - /path/to/data:/app/data
    ...

If the container supports PUID/PGID, you can also set these environment variables to achieve the same result. However, Grimoire doesn’t support PUID/PGID, so the --user method was the fix here.

The changes introduced by goniszewski in #162 should also help, but if issues persist, double-check your file permissions and try this approach.

Just started a new server for the first time. Using the docker compose user mechanism solved it for me.

BitBernd avatar Jan 25 '25 20:01 BitBernd

Without any additional feedback, I have merged the above PR to the preview as https://github.com/goniszewski/grimoire/releases/tag/v0.5.0-pre.2. You can check the goniszewski/grimoire:preview Docker image with the original docker-compose.yml and let me know if this resolved the issue for you.

Sorry for being so sluggish with this one.

EDIT: There is some issue with building the image, and I'm working on a fix for this.

goniszewski avatar Jan 30 '25 07:01 goniszewski

The above issue (and some related ones) should be now resolved. The Docker image is now even slimmer!

Please run it with the updated preview tag: docker pull goniszewski/grimoire:preview.

goniszewski avatar Feb 05 '25 20:02 goniszewski