Originally created by @Hobbabobba on GitHub (May 26, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2504
### Subject of the issue
Updated docker image to vaultwarden/server:1.25.0
After that container can´t start
### Deployment environment
<!--
=========================================================================================
Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab.
That will auto-generate most of the info requested in this section.
=========================================================================================
-->
<!-- The version number, obtained from the logs (at startup) or the admin diagnostics page -->
<!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden -->
<!-- Remember to check if your issue exists on the latest version first! -->
* vaultwarden version: 1.25.0
<!-- How the server was installed: Docker image, OS package, built from source, etc. -->
* Install method: Docker-Compose
```
version: "2"
services:
bitwarden:
image: vaultwarden/server
container_name: vaultwarden
environment:
- WEBSOCKET_ENABLED=true
- SIGNUPS_ALLOWED=false
- ADMIN_TOKEN=xxx
- SMTP_PASSWORD=xxxx
- SMTP_USERNAME=mail@domain.com
- SMTP_SSL=true
- SMTP_PORT=587
- SMTP_FROM=yyyy
- SMTP_HOST=yyy
volumes:
- /volume1/docker/bitwarden_rs:/data
ports:
- 3012:3012
- 6680:80
restart: always
```
* Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) -->
web vault
Desktop
Android
iOS
* Other relevant details:
### Steps to reproduce
<!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults)
and how did you start vaultwarden? -->
### Expected behaviour
<!-- Tell us what you expected to happen -->
### Actual behaviour
<!-- Tell us what actually happened -->
### Troubleshooting data
<!-- Share any log files, screenshots, or other relevant troubleshooting data -->
```
)
Running migration 20220302210038
Executing migration script 20220302210038/up.sql
[2022-05-26 21:23:36.150][vaultwarden::util][WARN] Can't connect to database, retrying: DieselMig.
[CAUSE] QueryError(
DatabaseError(
__Unknown,
"UNIQUE constraint failed: devices_new.uuid, devices_new.user_uuid",
),
)
```
<!-- gh-comment-id:1139093328 -->
@BlackDex commented on GitHub (May 26, 2022):
Please check https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset and follow the steps there. It probably has some wrong configuration on the database or tables.
<!-- gh-comment-id:1139103828 -->
@Hobbabobba commented on GitHub (May 26, 2022):
how can I do any of the steps in https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset ? Using the commands inside the docker cli does not work.
Hmm, it's a sqlite db it looks like.
Strange, the migration should just run.
<!-- gh-comment-id:1139108018 -->
@BlackDex commented on GitHub (May 26, 2022):
Hmm, it's a sqlite db it looks like.
Strange, the migration should just run.
if i don´t mount the data-volume the migration works and the container is running fine. After mount the volume again, the problem still occurs. Image 1.24.0 works without any problem.
<!-- gh-comment-id:1139114189 -->
@Hobbabobba commented on GitHub (May 26, 2022):
if i don´t mount the data-volume the migration works and the container is running fine. After mount the volume again, the problem still occurs. Image 1.24.0 works without any problem.
Can't contribute anything but say that I am having the exact same problem since 1.25.0 and had to revert back to version 1.24.0 where it still works.
No external DB configured, just the integrated sqlite inside the container.
I wonder what is the reason a migration script starts up?
<!-- gh-comment-id:1139680680 -->
@berotrip commented on GitHub (May 27, 2022):
Can't contribute anything but say that I am having the exact same problem since 1.25.0 and had to revert back to version 1.24.0 where it still works.
No external DB configured, just the integrated sqlite inside the container.
I wonder what is the reason a migration script starts up?
The reason is because there are some changes to the database.
I didn't had time yet to do some testing regarding this issue.
<!-- gh-comment-id:1139689952 -->
@BlackDex commented on GitHub (May 27, 2022):
The reason is because there are some changes to the database.
I didn't had time yet to do some testing regarding this issue.
Ok, i have tried several stuff to try and reproduce this but were not able to.
What could be the case here is that there is something wrong with the database it self. It might not be a big issue, but still.
Could someone try to do the following:
Create a backup of the database before you continue.
So, just copy over the db.sqlite3 file and rename it to something like backup_db.sqlite3 or what ever.
Now we need a second kinda of backup which is a bit different then just coping the file.
a. Either login into the admin interface, scroll all the way down there is a backup option there, run that, and there should be a new backup file generated next to the default database file.
b. Run sqlite command your self. I suggest to shutdown Vaultwarden first when you do this your self.
Go to the data folder where the db.sqlite3 file is located and run
sqlite3 db.sqlite3 "VACUUM INTO './db-vacumed.sqlite3'"
I any case, make sure to stop Vaultwarden.
Move/Rename the original db.sqlite3 file
Now Move/Rename the newly generated backuped/vacumed file to be db.sqlite3
Start Vaultwarden again, and see if this solves the issue.
<!-- gh-comment-id:1140252864 -->
@BlackDex commented on GitHub (May 28, 2022):
Ok, i have tried several stuff to try and reproduce this but were not able to.
What could be the case here is that there is something wrong with the database it self. It might not be a big issue, but still.
Could someone try to do the following:
1. Create a backup of the database before you continue.
So, just copy over the `db.sqlite3` file and rename it to something like `backup_db.sqlite3` or what ever.
2. Now we need a second kinda of backup which is a bit different then just coping the file.
a. Either login into the admin interface, scroll all the way down there is a backup option there, run that, and there should be a new backup file generated next to the default database file.
b. Run sqlite command your self. I suggest to shutdown Vaultwarden first when you do this your self.
Go to the data folder where the `db.sqlite3` file is located and run
```bash
sqlite3 db.sqlite3 "VACUUM INTO './db-vacumed.sqlite3'"
```
3. I any case, make sure to stop Vaultwarden.
4. Move/Rename the original `db.sqlite3` file
5. Now Move/Rename the newly generated backuped/vacumed file to be `db.sqlite3`
6. Start Vaultwarden again, and see if this solves the issue.
I tried the fix with a vacumed db, still the same problem after an update to 1.25.0
<!-- gh-comment-id:1140267516 -->
@Hobbabobba commented on GitHub (May 28, 2022):
I tried the fix with a vacumed db, still the same problem after an update to 1.25.0
Could you post a sqlite3 db.sqlite3 '.schema;' here?
Need to see what is wrong here.
<!-- gh-comment-id:1140267773 -->
@BlackDex commented on GitHub (May 28, 2022):
Could you post a `sqlite3 db.sqlite3 '.schema;'` here?
Need to see what is wrong here.
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE __diesel_schema_migrations (version VARCHAR(50) PRIMARY KEY NOT NULL,run_on TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP);
CREATE TABLE users (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
email TEXT NOT NULL UNIQUE,
name TEXT NOT NULL,
password_hash BLOB NOT NULL,
salt BLOB NOT NULL,
password_iterations INTEGER NOT NULL,
password_hint TEXT,
akey TEXT NOT NULL,
private_key TEXT,
public_key TEXT,
totp_secret TEXT,
totp_recover TEXT,
security_stamp TEXT NOT NULL,
equivalent_domains TEXT NOT NULL,
excluded_globals TEXT NOT NULL
, client_kdf_type INTEGER NOT NULL DEFAULT 0, client_kdf_iter INTEGER NOT NULL DEFAULT 100000, verified_at DATETIME DEFAULT NULL, last_verifying_at DATETIME DEFAULT NULL, login_verify_count INTEGER NOT NULL DEFAULT 0, email_new TEXT DEFAULT NULL, email_new_token TEXT DEFAULT NULL, enabled BOOLEAN NOT NULL DEFAULT 1, stamp_exception TEXT DEFAULT NULL, api_key TEXT);
CREATE TABLE devices (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
name TEXT NOT NULL,
atype INTEGER NOT NULL,
push_token TEXT,
refresh_token TEXT NOT NULL
, twofactor_remember TEXT);
CREATE TABLE folders (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
name TEXT NOT NULL
);
CREATE TABLE collections (
uuid TEXT NOT NULL PRIMARY KEY,
org_uuid TEXT NOT NULL REFERENCES organizations (uuid),
name TEXT NOT NULL
);
CREATE TABLE organizations (
uuid TEXT NOT NULL PRIMARY KEY,
name TEXT NOT NULL,
billing_email TEXT NOT NULL
, private_key TEXT, public_key TEXT);
CREATE TABLE users_collections (
user_uuid TEXT NOT NULL REFERENCES users (uuid),
collection_uuid TEXT NOT NULL REFERENCES collections (uuid), read_only BOOLEAN NOT NULL DEFAULT 0, hide_passwords BOOLEAN NOT NULL DEFAULT 0,
PRIMARY KEY (user_uuid, collection_uuid)
);
CREATE TABLE users_organizations (
uuid TEXT NOT NULL PRIMARY KEY,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
org_uuid TEXT NOT NULL REFERENCES organizations (uuid),
access_all BOOLEAN NOT NULL,
, reprompt INTEGER);
CREATE TABLE sends (
uuid TEXT NOT NULL PRIMARY KEY,
user_uuid TEXT REFERENCES users (uuid),
organization_uuid TEXT REFERENCES organizations (uuid),
name TEXT NOT NULL,
notes TEXT,
atype INTEGER NOT NULL,
data TEXT NOT NULL,
akey TEXT NOT NULL,
password_hash BLOB,
password_salt BLOB,
password_iter INTEGER,
max_access_count INTEGER,
access_count INTEGER NOT NULL,
creation_date DATETIME NOT NULL,
revision_date DATETIME NOT NULL,
expiration_date DATETIME,
deletion_date DATETIME NOT NULL,
disabled BOOLEAN NOT NULL
, hide_email BOOLEAN);
CREATE TABLE emergency_access (
uuid TEXT NOT NULL PRIMARY KEY,
grantor_uuid TEXT REFERENCES users (uuid),
grantee_uuid TEXT REFERENCES users (uuid),
email TEXT,
key_encrypted TEXT,
atype INTEGER NOT NULL,
status INTEGER NOT NULL,
wait_time_days INTEGER NOT NULL,
recovery_initiated_at DATETIME,
last_notification_at DATETIME,
updated_at DATETIME NOT NULL,
created_at DATETIME NOT NULL
);
CREATE TABLE twofactor_incomplete (
user_uuid TEXT NOT NULL REFERENCES users(uuid),
device_uuid TEXT NOT NULL,
device_name TEXT NOT NULL,
login_time DATETIME NOT NULL,
ip_address TEXT NOT NULL,
PRIMARY KEY (user_uuid, device_uuid)
);
sqlite>
Could the last line be relevant: device_uuid instead of the quoted devices_uuid from the error messages?
<!-- gh-comment-id:1140275744 -->
@berotrip commented on GitHub (May 28, 2022):
Here's the schema (no success with VACUUM):
```
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE __diesel_schema_migrations (version VARCHAR(50) PRIMARY KEY NOT NULL,run_on TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP);
CREATE TABLE users (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
email TEXT NOT NULL UNIQUE,
name TEXT NOT NULL,
password_hash BLOB NOT NULL,
salt BLOB NOT NULL,
password_iterations INTEGER NOT NULL,
password_hint TEXT,
akey TEXT NOT NULL,
private_key TEXT,
public_key TEXT,
totp_secret TEXT,
totp_recover TEXT,
security_stamp TEXT NOT NULL,
equivalent_domains TEXT NOT NULL,
excluded_globals TEXT NOT NULL
, client_kdf_type INTEGER NOT NULL DEFAULT 0, client_kdf_iter INTEGER NOT NULL DEFAULT 100000, verified_at DATETIME DEFAULT NULL, last_verifying_at DATETIME DEFAULT NULL, login_verify_count INTEGER NOT NULL DEFAULT 0, email_new TEXT DEFAULT NULL, email_new_token TEXT DEFAULT NULL, enabled BOOLEAN NOT NULL DEFAULT 1, stamp_exception TEXT DEFAULT NULL, api_key TEXT);
CREATE TABLE devices (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
name TEXT NOT NULL,
atype INTEGER NOT NULL,
push_token TEXT,
refresh_token TEXT NOT NULL
, twofactor_remember TEXT);
CREATE TABLE folders (
uuid TEXT NOT NULL PRIMARY KEY,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
name TEXT NOT NULL
);
CREATE TABLE collections (
uuid TEXT NOT NULL PRIMARY KEY,
org_uuid TEXT NOT NULL REFERENCES organizations (uuid),
name TEXT NOT NULL
);
CREATE TABLE organizations (
uuid TEXT NOT NULL PRIMARY KEY,
name TEXT NOT NULL,
billing_email TEXT NOT NULL
, private_key TEXT, public_key TEXT);
CREATE TABLE users_collections (
user_uuid TEXT NOT NULL REFERENCES users (uuid),
collection_uuid TEXT NOT NULL REFERENCES collections (uuid), read_only BOOLEAN NOT NULL DEFAULT 0, hide_passwords BOOLEAN NOT NULL DEFAULT 0,
PRIMARY KEY (user_uuid, collection_uuid)
);
CREATE TABLE users_organizations (
uuid TEXT NOT NULL PRIMARY KEY,
user_uuid TEXT NOT NULL REFERENCES users (uuid),
org_uuid TEXT NOT NULL REFERENCES organizations (uuid),
access_all BOOLEAN NOT NULL,
, reprompt INTEGER);
CREATE TABLE sends (
uuid TEXT NOT NULL PRIMARY KEY,
user_uuid TEXT REFERENCES users (uuid),
organization_uuid TEXT REFERENCES organizations (uuid),
name TEXT NOT NULL,
notes TEXT,
atype INTEGER NOT NULL,
data TEXT NOT NULL,
akey TEXT NOT NULL,
password_hash BLOB,
password_salt BLOB,
password_iter INTEGER,
max_access_count INTEGER,
access_count INTEGER NOT NULL,
creation_date DATETIME NOT NULL,
revision_date DATETIME NOT NULL,
expiration_date DATETIME,
deletion_date DATETIME NOT NULL,
disabled BOOLEAN NOT NULL
, hide_email BOOLEAN);
CREATE TABLE emergency_access (
uuid TEXT NOT NULL PRIMARY KEY,
grantor_uuid TEXT REFERENCES users (uuid),
grantee_uuid TEXT REFERENCES users (uuid),
email TEXT,
key_encrypted TEXT,
atype INTEGER NOT NULL,
status INTEGER NOT NULL,
wait_time_days INTEGER NOT NULL,
recovery_initiated_at DATETIME,
last_notification_at DATETIME,
updated_at DATETIME NOT NULL,
created_at DATETIME NOT NULL
);
CREATE TABLE twofactor_incomplete (
user_uuid TEXT NOT NULL REFERENCES users(uuid),
device_uuid TEXT NOT NULL,
device_name TEXT NOT NULL,
login_time DATETIME NOT NULL,
ip_address TEXT NOT NULL,
PRIMARY KEY (user_uuid, device_uuid)
);
sqlite>
```
Could the last line be relevant: device_uuid instead of the quoted device**s**_uuid from the error messages?
Seems to look fine. And those two items are totally different.
The only step left i can think of is that you need to clear the devices table.
You can do that by going to the admin interface /admin/users/overview and click on Deauthorize sessions for every user you have. That will force all clients to logout and they need to login again though.
But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?
<!-- gh-comment-id:1140281453 -->
@BlackDex commented on GitHub (May 28, 2022):
Seems to look fine. And those two items are totally different.
The only step left i can think of is that you need to clear the `devices` table.
You can do that by going to the admin interface `/admin/users/overview` and click on `Deauthorize sessions` for every user you have. That will force all clients to logout and they need to login again though.
But after you clicked on `Deauthorize sessions` for every user, try to upgrade again, and see if that helps?
But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?
That worked, thanks!
Running migration 20220302210038
[2022-05-28 16:00:00.409][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012.
<!-- gh-comment-id:1140289299 -->
@berotrip commented on GitHub (May 28, 2022):
> But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?
That worked, thanks!
```
Running migration 20220302210038
[2022-05-28 16:00:00.409][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012.
```
But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?
Fixed it!
<!-- gh-comment-id:1140292125 -->
@Hobbabobba commented on GitHub (May 28, 2022):
> But after you clicked on Deauthorize sessions for every user, try to upgrade again, and see if that helps?
Fixed it!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Hobbabobba on GitHub (May 26, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2504
Subject of the issue
Updated docker image to vaultwarden/server:1.25.0
After that container can´t start
Deployment environment
web vault
Desktop
Android
iOS
Steps to reproduce
Expected behaviour
Actual behaviour
Troubleshooting data
@BlackDex commented on GitHub (May 26, 2022):
Please check https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset and follow the steps there. It probably has some wrong configuration on the database or tables.
@Hobbabobba commented on GitHub (May 26, 2022):
how can I do any of the steps in https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend#foreign-key-errors-collation-and-charset ? Using the commands inside the docker cli does not work.
@BlackDex commented on GitHub (May 26, 2022):
Hmm, it's a sqlite db it looks like.
Strange, the migration should just run.
@Hobbabobba commented on GitHub (May 26, 2022):
if i don´t mount the data-volume the migration works and the container is running fine. After mount the volume again, the problem still occurs. Image 1.24.0 works without any problem.
@berotrip commented on GitHub (May 27, 2022):
Can't contribute anything but say that I am having the exact same problem since 1.25.0 and had to revert back to version 1.24.0 where it still works.
No external DB configured, just the integrated sqlite inside the container.
I wonder what is the reason a migration script starts up?
@BlackDex commented on GitHub (May 27, 2022):
The reason is because there are some changes to the database.
I didn't had time yet to do some testing regarding this issue.
@walmer26 commented on GitHub (May 28, 2022):
Same issue here.
@BlackDex commented on GitHub (May 28, 2022):
Ok, i have tried several stuff to try and reproduce this but were not able to.
What could be the case here is that there is something wrong with the database it self. It might not be a big issue, but still.
Could someone try to do the following:
So, just copy over the
db.sqlite3file and rename it to something likebackup_db.sqlite3or what ever.a. Either login into the admin interface, scroll all the way down there is a backup option there, run that, and there should be a new backup file generated next to the default database file.
b. Run sqlite command your self. I suggest to shutdown Vaultwarden first when you do this your self.
Go to the data folder where the
db.sqlite3file is located and rundb.sqlite3filedb.sqlite3@Hobbabobba commented on GitHub (May 28, 2022):
I tried the fix with a vacumed db, still the same problem after an update to 1.25.0
@BlackDex commented on GitHub (May 28, 2022):
Could you post a
sqlite3 db.sqlite3 '.schema;'here?Need to see what is wrong here.
@berotrip commented on GitHub (May 28, 2022):
Here's the schema (no success with VACUUM):
Could the last line be relevant: device_uuid instead of the quoted devices_uuid from the error messages?
@BlackDex commented on GitHub (May 28, 2022):
Seems to look fine. And those two items are totally different.
The only step left i can think of is that you need to clear the
devicestable.You can do that by going to the admin interface
/admin/users/overviewand click onDeauthorize sessionsfor every user you have. That will force all clients to logout and they need to login again though.But after you clicked on
Deauthorize sessionsfor every user, try to upgrade again, and see if that helps?@berotrip commented on GitHub (May 28, 2022):
That worked, thanks!
@Hobbabobba commented on GitHub (May 28, 2022):
Fixed it!