Images failing to load 500 internal server error

Bug
1

When I upgraded from 24.2 to 24.3 I noticed 500 internal server errors when images were loaded. Avatar and project backgrounds is where I noticed.
I was able to delete and replace the files, but then figured out what had happened - the path had changed, most likely related to changelog item (files) Use absolute path everywhere

Container logs showed:

2024-09-23T02:18:21Z: ERROR        ▶ 7f0 Error getting avatar for user 1: open /db/files/1: no such file or directory
2024-09-23T02:18:21Z: ERROR        ▶ 7f1 open /db/files/1: no such file or directory

Note the delete also failed to remove the file on disk:

2024-09-23T02:26:05Z: ERROR        ▶ bc2 Error deleting file 2: %!w(*fs.PathError=&{remove /db/files/2 2})
2024-09-23T02:26:05Z: WEB       ▶ 192.168.3.20  DELETE 200 /api/v1/projects/1/background 25.782568ms - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

It looks like files is now nested under ServiceRootPath where it wasn’t before. Found in diff here
The newly uploaded files were created in a new directory files under the ServiceRootPath. This is fine, it’s just not documented in the files.basepath documentation that it MUST be under there, and no existing data migration was done.

My config; docker compose based on the documentation (sqlite config on full docker example page) with separate volumes for db and files.

name: vikunja
services:
  vikunja:
    image: vikunja/vikunja:0.24.3
    volumes:
      - vikunja-files:/files
      - vikunja-config:/db
    environment:
      - VIKUNJA_SERVICE_ROOTPATH=/db
    restart: unless-stopped

And a config.yml in the /db volume:

database:
  type: sqlite
  path: /db/vikunja.db
files:
  basepath: /files

To aid in visualizing the change, here’s the structure of the 2 docker volumes contents:

vikunja-config <-- mounted on /db in the container
├── config.yml
├── files      <-- newly created files directory
│   └── 5      <-- newly uploaded
└── vikunja.db
vikunja-files  <-- mounted on /files in the container (original files directory)
└── 1          <-- original file

I have not yet tested if simply moving the files to the new location would work without any other update (might be an easy solution for other users).
If this files.basepath config was ok before, maybe log a warning if the setting starts with / and fallback to the original behaviour (or trigger a migration, but permissions might impact that).

Thank you for this amazing project.

2

Followup: I retested in a VM - config as per previous post.

vikunja/vikunja:0.24.2

├── vikunja-config
│   ├── config.yml
│   └── vikunja.db
└── vikunja-files
    ├── 1
    └── 2

Upgrade to vikunja/vikunja:0.24.3
On refreshing the page, images are now broken.

mkdir vikunja-config/files
chown 1000:1000 vikunja-config/files
mv vikunja-files/* vikunja-config/files/

Created the dir and moved the files.

├── vikunja-config
│   ├── config.yml
│   ├── files
│   │   ├── 1
│   │   └── 2
│   └── vikunja.db
└── vikunja-files

Refreshing the page the images now show correctly again.

3

Looks like that was an issue - the files should not be using the rootpath when the directory is explicitely set (fixed that in 261c6e6c9e).

Is there any particular reason why you set the root path to /db?

4

No specific reason, I just wanted the configuration and sqlite db to be in a volume, and the example showed files being separate.
I deploy using ansible, so I drop the config.yml file (with OIDC config setup) into the volume before the container starts.
Now I understand better how files are handled, it probably makes sense (at least for my deployment) to have both the database and the files directory in the same volume anyway.

1 Like