No user found - Problem with database?


I use Vikunja since 2 days. It runs on my own server with docker and portainer.
I had a problem with my Nginx Proxy Manager, so I have delete Nginx Proxy Manager and fetch a new SSL Certificate.

Now I have the problem, that I can’t log in Vikunja.

The volume from the data and the the database looks fine, from the timestamp.
Can I save my data from the database or what can I do to login in Vikunja?

Best regards


the Nginx proxy should not have any influence on authentication. Do you see anything in the browser console, network tab and/or Vikunja server logs?

If nothing helps0, you can use the Vinkunja CLI to reset the user password

1 Like

Thank you, it helps me a lot.

I see in the docs, that a dump file is possible, that’s great.

docker exec vikunja-vikunja-1 /app/vikunja/vikunja dump

How can I transfer the dump file out of the volume?

To be honest I am not sure how the dump would help you if you cannot login.

If you insist on just copying the file, check this:

Alternatively the volumes (by default) map to a folder on your file system. You can copy the file from there too.

1 Like

Now I have an othier issue with the databse. I recreated my docker-compose file and now I have an error :frowning: [Warning] Aborted connection 160 to db: ‘vikunja’ user: ‘vikunja’ host: ‘’ (Got an error reading communication packets)

How can I reconnected to my database?

root@docker-service:/var/lib/docker/volumes/vikunja_db/_data# docker exec vikunja-vikunja-1 /app/vikunja/vikunja user list
2024-04-25T23:34:23.434301722Z: INFO :arrow_forward: config/InitConfig 001 No config file found, using default or config from environment variables.
2024-04-25T23:34:23.456730487Z: INFO :arrow_forward: migration/Migrate 05b Ran all migrations successfully.
2024-04-25T23:34:23.456814997Z: INFO :arrow_forward: models/RegisterReminderCron 05c Mailer is disabled, not sending reminders per mail
2024-04-25T23:34:23.45685142Z: INFO :arrow_forward: models/RegisterOverdueReminderCron 05d Mailer is disabled, not sending overdue per mail

The logfile from the database container is:

2024-04-25 23:28:59+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.7+maria~ubu2204 started.
2024-04-25 23:28:59+00:00 [Warn] [Entrypoint]: /sys/fs/cgroup///memory.pressure not writable, functionality unavailable to MariaDB
2024-04-25 23:28:59+00:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’
2024-04-25 23:28:59+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.7+maria~ubu2204 started.
2024-04-25 23:29:00+00:00 [Note] [Entrypoint]: MariaDB upgrade not required
2024-04-25 23:29:00 0 [Note] Starting MariaDB 10.11.7-MariaDB-1:10.11.7+maria~ubu2204 source revision 87e13722a95af5d9378d990caf48cb6874439347 as process 1
2024-04-25 23:29:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-04-25 23:29:00 0 [Note] InnoDB: Using transactional memory
2024-04-25 23:29:00 0 [Note] InnoDB: Number of transaction pools: 1
2024-04-25 23:29:00 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2024-04-25 23:29:00 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2024-04-25 23:29:00 0 [Warning] mariadbd: io_uring_queue_init() failed with errno 1
2024-04-25 23:29:00 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
2024-04-25 23:29:00 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2024-04-25 23:29:00 0 [Note] InnoDB: Completed initialization of buffer pool
2024-04-25 23:29:00 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
2024-04-25 23:29:00 0 [Note] InnoDB: End of log at LSN=358851
2024-04-25 23:29:00 0 [Note] InnoDB: 128 rollback segments are active.
2024-04-25 23:29:00 0 [Note] InnoDB: Setting file ‘./ibtmp1’ size to 12.000MiB. Physically writing the file full; Please wait …
2024-04-25 23:29:00 0 [Note] InnoDB: File ‘./ibtmp1’ size is now 12.000MiB.
2024-04-25 23:29:00 0 [Note] InnoDB: log sequence number 358851; transaction id 842
2024-04-25 23:29:00 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2024-04-25 23:29:00 0 [Note] Plugin ‘FEEDBACK’ is disabled.
2024-04-25 23:29:00 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2024-04-25 23:29:00 0 [Note] Server socket created on IP: ‘’.
2024-04-25 23:29:00 0 [Note] Server socket created on IP: ‘::’.
2024-04-25 23:29:00 0 [Note] mariadbd: ready for connections.
Version: ‘10.11.7-MariaDB-1:10.11.7+maria~ubu2204’ socket: ‘/run/mysqld/mysqld.sock’ port: 3306 binary distribution
2024-04-25 23:29:00 0 [Note] InnoDB: Buffer pool(s) load completed at 240425 23:29:00
2024-04-25 23:34:23 160 [Warning] Aborted connection 160 to db: ‘vikunja’ user: ‘vikunja’ host: ‘’ (Got an error reading communication packets)

My docker compose file is

version: ‘3’

image: vikunja/vikunja:latest
- 3456:3456
- /var/lib/docker/volumes/vikunja_files/_data/:/app/vikunja/files
condition: service_healthy
restart: unless-stopped
image: mariadb:10
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
MYSQL_USER: vikunja
- /var/lib/docker/volumes/vikunja_db/_data/:/var/lib/mysql
restart: unless-stopped
test: [“CMD-SHELL”, “mysqladmin ping -h localhost -u $$MYSQL_USER --password=$$MYSQL_PASSWORD”]
interval: 2s
start_period: 30s

This seems normal since the user list command exited after it printed the output.

Does Vikunja itself work?

Sadly Vikunja doesnt work. Now my database is empty.

I can see the database in the docker container

docker exec -it vikunja-db-1 /bin/bash

mysql -u vikunja -p
MariaDB [(none)]> SHOW DATABASES;
| Database |
| information_schema |
| vikunja |

MariaDB [(none)]> use vikunja
MariaDB [vikunja]> SHOW tables;
MariaDB [vikunja]> SELECT * FROM users;
Empty set (0.000 sec)

Well, the user list command does not change any data, it only shows users. Does it work if you restore from backup?

My best guess right now is something was messed up when you restarted the container after the certificate change.