Vault loading issues (attachments?) #2484
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Strange, that doesn't happen at all for me. |
|
@tophers that looks more like a |
I only have one account on my instance, otherwise I would've tested that yesterday. I'll be closing this, since I can't even reproduce it myself. |
|
hello, I have the same issue. I understand completely, but it would be good to keep this issue opened until a solution is found. for myself, after the upgrade from 1.24 to 1.25 the container won't start because of ROCKET_CLI_COLORS variable value. after fixing that, the container start well, no errors into the log file. but when I try to access to url "/#/vault", the error message "Commands out of sync; you can't run this command now" appear into the log and no items is displayed on the web page. My log : |
|
@jzahraoui could you post your |
|
I have exactly the same issue. reverting 1.24 resolved for now. Below is the support string. Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)Show Running ConfigEnvironment settings which are overridden: {
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": true,
"_enable_smtp": true,
"_enable_yubico": true,
"_ip_header_enabled": true,
"admin_ratelimit_max_burst": 3,
"admin_ratelimit_seconds": 300,
"admin_token": "***",
"allowed_iframe_ancestors": "",
"attachments_folder": "data/attachments",
"authenticator_disable_time_drift": false,
"data_folder": "data",
"database_conn_init": "",
"database_max_conns": 10,
"database_timeout": 30,
"database_url": "*****://************:*********@***@**.*.*.*:****/*********",
"db_connection_retries": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": false,
"domain": "*****://*********.****.***/",
"domain_origin": "*****://*********.****.***",
"domain_path": "",
"domain_set": true,
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"email_attempts_limit": 3,
"email_expiration_time": 600,
"email_token_size": 6,
"emergency_access_allowed": true,
"emergency_notification_reminder_schedule": "0 5 * * * *",
"emergency_request_timeout_schedule": "0 5 * * * *",
"enable_db_wal": true,
"extended_logging": true,
"helo_name": null,
"hibp_api_key": null,
"icon_blacklist_non_global_ips": true,
"icon_blacklist_regex": null,
"icon_cache_folder": "data/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"icon_redirect_code": 302,
"icon_service": "internal",
"incomplete_2fa_schedule": "30 * * * * *",
"incomplete_2fa_time_limit": 3,
"invitation_org_name": "Vaultwarden",
"invitations_allowed": true,
"ip_header": "X-Real-IP",
"job_poll_interval_ms": 30000,
"log_file": "/data/vaultwarden.log",
"log_level": "Info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"login_ratelimit_max_burst": 10,
"login_ratelimit_seconds": 60,
"org_attachment_limit": null,
"org_creation_users": "",
"password_iterations": 100000,
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "data/rsa_key",
"send_purge_schedule": "0 5 * * * *",
"sends_allowed": true,
"sends_folder": "data/sends",
"show_password_hint": false,
"signups_allowed": true,
"signups_domains_whitelist": "",
"signups_verify": false,
"signups_verify_resend_limit": 6,
"signups_verify_resend_time": 3600,
"smtp_accept_invalid_certs": false,
"smtp_accept_invalid_hostnames": false,
"smtp_auth_mechanism": null,
"smtp_debug": false,
"smtp_explicit_tls": null,
"smtp_from": "*****.***@*******.***",
"smtp_from_name": "Vaultwarden",
"smtp_host": "****.*********.***",
"smtp_password": "***",
"smtp_port": 587,
"smtp_security": "starttls",
"smtp_ssl": true,
"smtp_timeout": 15,
"smtp_username": "*****.***@*******.***",
"templates_folder": "data/templates",
"tmp_folder": "data/tmp",
"trash_auto_delete_days": null,
"trash_purge_schedule": "0 5 0 * * *",
"use_syslog": false,
"user_attachment_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"websocket_address": "0.0.0.0",
"websocket_enabled": true,
"websocket_port": 3012,
"yubico_client_id": null,
"yubico_secret_key": null,
"yubico_server": null
} |
|
Hello I revert back to 1.24, but here is the support string. let me know if you want the support string for the 1.25 Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)Show Running ConfigEnvironment settings which are overridden: {
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": true,
"_enable_smtp": true,
"_enable_yubico": true,
"_ip_header_enabled": true,
"admin_ratelimit_max_burst": 3,
"admin_ratelimit_seconds": 300,
"admin_token": "***",
"allowed_iframe_ancestors": "",
"attachments_folder": "data/attachments",
"authenticator_disable_time_drift": false,
"data_folder": "data",
"database_max_conns": 10,
"database_url": "*****://************:********************************@***.***.*.***/************",
"db_connection_retries": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": false,
"domain": "*****://****.**********.***/",
"domain_origin": "*****://****.**********.***",
"domain_path": "",
"domain_set": true,
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"email_attempts_limit": 3,
"email_expiration_time": 600,
"email_token_size": 6,
"emergency_access_allowed": true,
"emergency_notification_reminder_schedule": "0 5 * * * *",
"emergency_request_timeout_schedule": "0 5 * * * *",
"enable_db_wal": true,
"extended_logging": true,
"helo_name": null,
"hibp_api_key": null,
"icon_blacklist_non_global_ips": true,
"icon_blacklist_regex": null,
"icon_cache_folder": "data/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"icon_redirect_code": 302,
"icon_service": "internal",
"incomplete_2fa_schedule": "30 * * * * *",
"incomplete_2fa_time_limit": 3,
"invitation_org_name": "Bitwarden",
"invitations_allowed": true,
"ip_header": "X-Real-IP",
"job_poll_interval_ms": 30000,
"log_file": "/var/log/bitwarden/bitwarden.log",
"log_level": "info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"login_ratelimit_max_burst": 10,
"login_ratelimit_seconds": 60,
"org_attachment_limit": null,
"org_creation_users": "",
"password_iterations": 100000,
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "data/rsa_key",
"send_purge_schedule": "0 5 * * * *",
"sends_allowed": true,
"sends_folder": "data/sends",
"show_password_hint": true,
"signups_allowed": false,
"signups_domains_whitelist": "",
"signups_verify": true,
"signups_verify_resend_limit": 6,
"signups_verify_resend_time": 3600,
"smtp_accept_invalid_certs": false,
"smtp_accept_invalid_hostnames": false,
"smtp_auth_mechanism": null,
"smtp_debug": false,
"smtp_explicit_tls": false,
"smtp_from": "*********@**********.***",
"smtp_from_name": "Bitwarden_RS",
"smtp_host": "***.***.*.***",
"smtp_password": null,
"smtp_port": 25,
"smtp_ssl": true,
"smtp_timeout": 15,
"smtp_username": null,
"templates_folder": "data/templates",
"trash_auto_delete_days": null,
"trash_purge_schedule": "0 5 0 * * *",
"use_syslog": false,
"user_attachment_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"websocket_address": "0.0.0.0",
"websocket_enabled": true,
"websocket_port": 3012,
"yubico_client_id": null,
"yubico_secret_key": null,
"yubico_server": null
} |
BlackDex
added
bug
|
Ok, it looks like you all at running MariaDB. Change SHOW CREATE TABLE `attachments`;
--- And also run
SHOW CREATE DATABASE `vaultwarden`; |
|
MariaDB [vaultwarden]> SHOW CREATE TABLE MariaDB [vaultwarden]> SHOW CREATE DATABASE |
|
I tried several times to cause this exact same issue on my environment but I'm not able to. Could you try to repair at least the attachment table, and maybe also the others if that isn't fixing it? |
|
I ran mysqlcheck on the vaultwarden database, the problem remains. |
|
@PeterRob what did you exactly run? |
|
|
So, did you tested after the optimize? |
|
Yes I tested after optimisation There are no attachments - both users and organizations. |
|
Strange. I'm really unable to reproduce this at all. |
|
Could you provide a bit more info on the host where this is running? Because i tried using the exact same MariaDB, but that isn't causing an issue for me at all. Also, what happens if you create a new user, does it happen for that user also? If i could cause this my self i wouldn't need to ask these questions, but unfortunately that is not the case. |
|
is this can help : rwf2/Rocket#400 ? |
That is very very old, and both Rocket and Diesel are updated to newer version already. |
|
tried to investigate. May be the se select have to much elements into the "IN" clause. counted 3213 elements. find some people saying the max is 1000 but don't have the clue. put vaultwarden log level to trace. unfortunately not helping. |
|
to compare the version 1.24.0 give this query trace : |
|
Yes, that has changed to improve sync. There isn't a hardcoded limitation on the amount. I have tested 6000+ items during the development. I would suggest to see if changing that |
|
tried |
|
Have you tried creating an organization on 1.25 and check if you get the issue ? |
|
yes I tried. It return the error when I try to create an organization. but when I revert back to 1.24 the organization appear. |
|
@jzahraoui does that new user have more then 1000 items? |
|
my user have 3143 items, it is not working. |
|
How much memory does the system have which is running MariaDB? |
|
Having 32gb of ram but running some other process. Turned some innodb parameters. |
|
I made a new user account and progressively added logins (plain logins, no attachments). Syncing the vault failed at 1,000 logins added to the account. |
|
It probably has something to do with The It would be interesting to see what happens if you put the Also see: https://mariadb.com/kb/en/conversion-of-big-in-predicates-into-subqueries/ |
|
Setting in_predicate_conversion_threshold to 4000 = success! |
|
Good to see that that is a working solution. Still strange, as i understand the documentation correctly that MariaDB only uses that value to split the IN() clause into multiple IN() clauses or something like that. And me having it set to 200, and having 6000+ entries in there does work without any issue. I'm going to see if i can figure out how i can trigger this my self, maybe it's a bug in the specific MariaDB version used by Debian, that is something i did not try yet. |
BlackDex
added
wontfix
|
I tried and tried, and nothing seemed to break on my testing environments what ever i tried. Then i went to ask for some help on IRC from the MariaDB Devs, and they mentioned this was a bug in the exact version you are using. It seems that both Ubuntu and Debian didn't updated there packages yet, or cherry-picked that fix into there builds. It is fixed in For some more information see the following links: I'm afraid that we can't fix this on the client (Vaultwarden) side. So, what they suggest is to set Because of this, i will close this issue. |
Subject of the issue
After updating from 1.24.0 to 1.25.0, I am having issues loading my vault.
Error messages indicate issues with attachments (included error logs under "Troubleshooting data").
Other account settings seem to work fine (changing equivalent domains or updating 2FA settings still worked), so it seems to only affect the vault data.
No issues on 1.24.0. In fact, I could revert Vaultwarden back to 1.24.0 without restoring my database from backups and the vault seems to load just fine again. Syncing from the browser extension works fine too.
Deployment environment
Install method: Docker
Clients used: Web vault & official browser extension
MySQL/MariaDB or PostgreSQL version:
10.5.15-MariaDB-1:10.5.15+maria~focalSteps to reproduce
Docker Compose with the
latesttag, upgrade from 1.24.0 (pull, down, up)No other changes were done, except using
1.24.0instead of latest when reverting back.Log into web vault / sync with browser extension.
Actual behaviour
Web vault was empty with no entries. Browser extension (where previously logged in & synced) just returned a sync error.
Troubleshooting data
The text was updated successfully, but these errors were encountered: