Vikunja cannot start with the new unified version update

Support
1

The problem:

Hello :wave:,

I have a Portainer instance running on a Raspberry Pi hosting Vikinja’s container.
I tried updating from the old docker-compose config (the one with api and front containers) but using the new unified version I got a problem.

My container’s log is only showing me this error:

info: creating the new user vikunja with 1000:1000
usermod: no changes

And after that it shut down.


What I tried:

  • I tried changing the user in the compose file by using user: "1000" or user: "2000:2000" but every time I try something like that I get this error:
info: creating the new user vikunja with 1000:1000
groupmod: /etc/group.8: Permission denied
groupmod: cannot lock /etc/group; try again later.
  • I tried running Vikunja on Windows, it worked (I saw that the directory was set to the Vikunja 1000 user and that the bash was running as root) for the first launch, but after I tried copying what I did on Linux it broke with the error as above.
  • I tried changing the PGID and PUID environment variables of the container, same as before.
  • I tried chowning the volumes host paths for my mounts.

Btw my db is intact and working.


My conclusions:

My pi user on my host has the UID 1000. What I think is that there is an overlap with the docker namespace.
So trying to change it with --user/user: was the solution, but the container doesn’t seem to be able to work with such a change.

Can you help me find a solution to this other than changing my user UID or tweaking my docker host config (that I can accept it if needed)? Thanks in advance.


Resources

My actual Docker-Compose.yaml 
version: '3'
services:
vikunja:
  image: vikunja/vikunja
  environment:
    VIKUNJA_SERVICE_PUBLICURL: "${URL}"
    VIKUNJA_DATABASE_HOST: db
    VIKUNJA_DATABASE_PASSWORD: ${PWD}
    VIKUNJA_DATABASE_TYPE: sqlite
    VIKUNJA_DATABASE_USER: vikunja
    VIKUNJA_DATABASE_PATH: /db/vikunja.db
    VIKUNJA_SERVICE_JWTSECRET: <generated secret>
    VIKUNJA_SERVICE_ENABLEREGISTRATION: false
  ports:
    - 3456:3456
  volumes:
    - "${BASE_PATH}/files:/app/vikunja/files"
    - "${BASE_PATH}/db:/db"
  restart: unless-stopped
2

have u found a solution to this yet? i m having trouble getting user: 1000:1000 work with latest tag. only works in unstable tag but i cant get inside container to check it then.

3

I think that is related to another problem, not a permission issue. The message you’re seeing is an info message.
Which exit code does the container exit with? Is there anything in the logs? Are you running rootless?

Specifying the user as indicated in the docs is only supported starting with the next release, or with a current unstable build.
The new container only contains the Vikunja binary, nothing else, hence you can’t run anything in there. This minimizes the potential attack surface by a lot because we’re essentially only shipping the Binary and don’t need to worry about the rest of the OS in the container.

4

then i will wait for next stable release. i dont like unstable. thank you for replying.

5

Hello, thanks for your help.

I’m running into a exit 10 error code with the old config.

Then I tried using the unstable version it was the same.

version: '3'

services:
  vikunja:
    image: vikunja/vikunja:unstable
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://${URL}/
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: ${PWD}
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_PATH: /db/vikunja.db
      VIKUNJA_SERVICE_JWTSECRET: <generated secret>
      VIKUNJA_SERVICE_ENABLEREGISTRATION: false
      VIKUNJA_SERVICE_TIMEZONE: 'Europe/Paris'
    ports:
      - 3456:3456
    volumes:
      - "${BASE_PATH}/files:/app/vikunja/files"
      - "${BASE_PATH}/db:/db"
    restart: unless-stopped
6

Was there anything in the logs?

7

With the unstable version I get a No log line matching the '' filter and that’s all.

I will try to install it on an Ubuntu x86_64 just to see if ARMv7 is the problem (because it worked on Windows in one of my tests).

8

Hello,

Sorry for the late reply.
So I tried running it (:unstable) on my x86_64 server and it didn’t crash at startup.
So for me the discriminatory factor is the architecture.
Don’t know if it will help you.
Thanks for your help.

9

So it does work now?

1 Like
10

No. As I said before, running it somewhere else than on my Pi is good but that’s the only way. So I think the problem is on the CPU arch.

11

Which Pi are you running? Does it work if you manually specify the arch? (you’ll need to use the sha hash from one of the layers from this list directly)

12

Hello.

I forgot to say it but I already tried that.
I will give it a go again on my Raspberry Pi 4 and come back to you.

13

Hello.
So I tried again on my Pi with this (the latest unstable ARMv7) :
vikunja/vikunja@sha256:351a625c95363f35b019e126262a4eed102807a13573519ee167887ad8486f5d@sha256:f470169f903f3771ccbab29af2f0fbb37c2bcbae92d0f8dd6a63dc9d71fe6a5e
And I got the same. I don’t know if other users of a Raspberry Pi are having the same problem or if it is mine that is flawed.
What should I do with this discussion ?

Thanks.

14

Does it work if you use any of the other arm variants?

15

Using ARMv6 it worked !
vikunja/vikunja@sha256:8a59e4f57efb2250cc0ef4e652ac76af3c43e0e3424464e9a0dd88c7566d768d
Thanks for all.

16

I will try to come back to the latest ARMv7 version next time to see if maybe it was a problem of bad image arch being downloaded and edit my comment.
Thanks for your support and time working on this great software. Hope it will last.