Hi,
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
Hi,
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
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.
Now I have an othier issue with the databse. I recreated my docker-compose file and now I have an error 
[Warning] Aborted connection 160 to db: ‘vikunja’ user: ‘vikunja’ host: ‘172.18.0.3’ (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: INFOconfig/InitConfig 001 No config file found, using default or config from environment variables.
2024-04-25T23:34:23.456730487Z: INFO
2024-04-25T23:34:23.456814997Z: INFO
2024-04-25T23:34:23.45685142Z: INFO
±—±---------±------±-------±--------±--------+
| ID | USERNAME | EMAIL | STATUS | CREATED | UPDATED |
±—±---------±------±-------±--------±--------+
±—±---------±------±-------±--------±--------+
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: ‘0.0.0.0’.
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 mariadb.org 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: ‘172.18.0.3’ (Got an error reading communication packets)
My docker compose file is
version: ‘3’
services:
vikunja:
image: vikunja/vikunja:latest
environment:
VIKUNJA_SERVICE_PUBLICURL: task.
VIKUNJA_DATABASE_HOST: db
VIKUNJA_DATABASE_PASSWORD:
VIKUNJA_DATABASE_TYPE: mysql
VIKUNJA_DATABASE_USER: vikunja
VIKUNJA_DATABASE_DATABASE: vikunja
VIKUNJA_SERVICE_JWTSECRET:
ports:
- 3456:3456
volumes:
- /var/lib/docker/volumes/vikunja_files/_data/:/app/vikunja/files
depends_on:
db:
condition: service_healthy
restart: unless-stopped
db:
image: mariadb:10
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
environment:
MYSQL_ROOT_PASSWORD:
MYSQL_USER: vikunja
MYSQL_PASSWORD:
MYSQL_DATABASE: vikunja
volumes:
- /var/lib/docker/volumes/vikunja_db/_data/:/var/lib/mysql
restart: unless-stopped
healthcheck:
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.
