github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-08-04 02:56:58 -05:00
Code Issues 534 Packages Projects Releases 85 Wiki Activity

Emergency access fails if grantor doesnt log in during waiting time #5053

New Issue
Closed
opened 2026-03-07 20:11:06 -06:00 by GiteaMirror · 16 comments
GiteaMirror commented 2026-03-07 20:11:06 -06:00
Owner
Copy Link
Copy Source

Originally created by @SoleroTG on GitHub (Nov 18, 2022).

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

When the grantee requests access to the grantor's vault, access isn't possible after the wait time if the grantor hasn't logged in during that time. Although the grantee received the Emergency access request for John Doe approved email, the Emergency Access tab of the grantee's account just lists the tags Emergency Access Initiated and View for the grantor user.

Deployment environment

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.26.0
  • Web-vault version: v2022.10.0
  • Running within Docker: true (Base: Debian)
  • Environment settings overridden: true
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: SQLite
  • Database version: 3.35.4
  • Clients used:
  • Reverse proxy and version:
  • Other relevant information:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: DOMAIN, ADMIN_TOKEN, ALLOWED_IFRAME_ANCESTORS, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_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": true,
  "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_expiration_hours": 120,
  "invitation_org_name": "Bitwarden",
  "invitations_allowed": false,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "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_hints_allowed": false,
  "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": 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": "\"Plain\"",
  "smtp_debug": false,
  "smtp_explicit_tls": null,
  "smtp_from": "*******@*****.******.**",
  "smtp_from_name": "Bitwarden",
  "smtp_host": "****.******.**",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": null,
  "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
}

Steps to reproduce

  1. Create two users grantor and grantee
  2. grantor is allowed to create organisations, grantee is not
  3. grantor is owner in one group and grantee is user the same group
  4. grantor grants grantee View access after one day of waiting
  5. grantor logs out of all of his clients
  6. grantee request access from grantor
  7. grantor does not log in during that waiting time
  8. grantee logs in and navigates to Emergency Access after receiving the Emergency access request for grantor approved email
  9. the only available option for grantee when clicking the kebab menu is Remove

Expected behaviour

Grantee is able to access grantors vault after the waiting time.

Actual behaviour

Grantee cannot access grantors vault after the waiting time.

Originally created by @SoleroTG on GitHub (Nov 18, 2022). Originally assigned to: @BlackDex on GitHub. <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue When the grantee requests access to the grantor's vault, access isn't possible after the wait time if the grantor hasn't logged in during that time. Although the grantee received the `Emergency access request for John Doe approved` email, the `Emergency Access` tab of the grantee's account just lists the tags `Emergency Access` Initiated and `View` for the grantor user. ### Deployment environment #### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.26.0 * Web-vault version: v2022.10.0 * Running within Docker: true (Base: Debian) * Environment settings overridden: true * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.35.4 * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** DOMAIN, ADMIN_TOKEN, ALLOWED_IFRAME_ANCESTORS, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_AUTH_MECHANISM ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_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": true, "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_expiration_hours": 120, "invitation_org_name": "Bitwarden", "invitations_allowed": false, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "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_hints_allowed": false, "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": 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": "\"Plain\"", "smtp_debug": false, "smtp_explicit_tls": null, "smtp_from": "*******@*****.******.**", "smtp_from_name": "Bitwarden", "smtp_host": "****.******.**", "smtp_password": "***", "smtp_port": 465, "smtp_security": "force_tls", "smtp_ssl": null, "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 } ``` </details> ### Steps to reproduce 1. Create two users _grantor_ and _grantee_ 2. _grantor_ is allowed to create organisations, _grantee_ is not 3. _grantor_ is owner in one group and _grantee_ is user the same group 4. grantor grants grantee `View` access after one day of waiting 5. grantor logs out of all of his clients 6. grantee request access from grantor 7. grantor does not log in during that waiting time 8. grantee logs in and navigates to `Emergency Access` after receiving the `Emergency access request for grantor approved` email 9. the only available option for grantee when clicking the kebab menu is `Remove` ### Expected behaviour Grantee is able to access grantors vault after the waiting time. ### Actual behaviour Grantee cannot access grantors vault after the waiting time.
GiteaMirror added the enhancementbug labels 2026-03-07 20:11:06 -06:00
GiteaMirror commented 2026-03-07 20:11:07 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 18, 2022):

I have tested this just last week. And it all seems to work fine it looks like.

  1. Are you sure the wait time is over?
  2. What is the current status in the database? (emergency_access table).

If you are able to, please copy/paste/provide the following columns of the record you think is in error.

  • atype
  • status
  • wait_time_days
  • recovery_initiated_at
  • last_notification_at
  • updated_at
  • created_at

Also, please enable LOG_LEVEL=debug, that should provide some more info regarding the jobs running for the emergency access.

Also remember that the wait-time is checked during the scheduled job. That job is executed every hour at minute 5 of that hour.
So, 11:05, 12:05, 13:05 etc... If for example that requested timestamp is 13:06 the previous day, then you will have to wait for 14:05 for that request to be triggered.

Please provide the requested info so that we can try to help.

@BlackDex commented on GitHub (Nov 18, 2022): I have tested this just last week. And it all seems to work fine it looks like. 1. Are you sure the wait time is over? 2. What is the current status in the database? (`emergency_access` table). If you are able to, please copy/paste/provide the following columns of the record you think is in error. - `atype` - `status` - `wait_time_days` - `recovery_initiated_at` - `last_notification_at` - `updated_at` - `created_at` Also, please enable `LOG_LEVEL=debug`, that should provide some more info regarding the jobs running for the emergency access. Also remember that the `wait-time` is checked during the scheduled job. That job is executed every hour at minute 5 of that hour. So, `11:05`, `12:05`, `13:05` etc... If for example that requested timestamp is `13:06` the previous day, then you will have to wait for `14:05` for that request to be triggered. Please provide the requested info so that we can try to help.
GiteaMirror commented 2026-03-07 20:11:07 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 18, 2022):

Thanks for the fast reply.
I tested it twice with a wait time of one hour. I tried to access the grantors vault after I received the email Emergency access request for grantor approved. I didn't wait much longer and reset both accounts afterwards. I run another try and post the results here, as requested.

@SoleroTG commented on GitHub (Nov 18, 2022): Thanks for the fast reply. I tested it twice with a wait time of one hour. I tried to access the grantors vault after I received the email `Emergency access request for grantor approved`. I didn't wait much longer and reset both accounts afterwards. I run another try and post the results here, as requested.
GiteaMirror commented 2026-03-07 20:11:08 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 18, 2022):

There is no wait time of an hour. There is a minimum of 1day.
So, if you expected it to be one hour, that is mistaken.

@BlackDex commented on GitHub (Nov 18, 2022): There is no wait time of an hour. There is a minimum of 1day. So, if you expected it to be one hour, that is mistaken.
GiteaMirror commented 2026-03-07 20:11:08 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 18, 2022):

Thanks for the correction. I meant one day, of course.

@SoleroTG commented on GitHub (Nov 18, 2022): Thanks for the correction. I meant one day, of course.
GiteaMirror commented 2026-03-07 20:11:09 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 19, 2022):

The already active run finished like the ones before.
I received the Emergency access request for grantor approved email at 17:05. Accessing the vault via grantee did not work.
After one and two hours later I still wasn't able to access the vault.

Now I set LOG_LEVEL=debug.

In the emergency_access table in db.sqlite3 I find
atype=0
status=3
wait_time_days=1
recovery_initiated_at=2022-11-18 15:39:15.342045184
last_notification_at=2022-11-18 15:39:15.342045184
updated_at=2022-11-19 18:05:16.410392218
created_at=2022-11-18 15:37:51.165740427

This confuses me as no emergency access is neither active nor pending.

I never messed with the database and just access the db via a offsite copy I took beforehand.

Should I still retry a new emergency access test? I think, that the entry in the emergency_access table situation should be solved before doing so.

@SoleroTG commented on GitHub (Nov 19, 2022): The already active run finished like the ones before. I received the `Emergency access request for grantor approved` email at 17:05. Accessing the vault via _grantee_ did not work. After one and two hours later I still wasn't able to access the vault. Now I set `LOG_LEVEL=debug`. In the `emergency_access` table in db.sqlite3 I find `atype=0` `status=3` `wait_time_days=1` `recovery_initiated_at=2022-11-18 15:39:15.342045184` `last_notification_at=2022-11-18 15:39:15.342045184` `updated_at=2022-11-19 18:05:16.410392218` `created_at=2022-11-18 15:37:51.165740427` This confuses me as no emergency access is neither active nor pending. I never messed with the database and just access the db via a offsite copy I took beforehand. Should I still retry a new emergency access test? I think, that the entry in the emergency_access table situation should be solved before doing so.
GiteaMirror commented 2026-03-07 20:11:09 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 19, 2022):

Strange, it does mention it was updated, but the status is still at 3, which i think from the top of my mind should be 4.

Please enable debug log level, and keep it running. It should keep trying the same, since the status is not correct yet.

@BlackDex commented on GitHub (Nov 19, 2022): Strange, it does mention it was updated, but the status is still at 3, which i think from the top of my mind should be 4. Please enable debug log level, and keep it running. It should keep trying the same, since the status is not correct yet.
GiteaMirror commented 2026-03-07 20:11:10 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 20, 2022):

Just a small update:
The emergency_access table still shows the same content, although no emergency job being neither active no pending. Should I expect a cronjob fixing the entry?

The only log entries related to this are:

[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_notification_reminder_job
[2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_request_timeout_job
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request timeout to approve
[2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request reminder notification to send

I'm grateful for any advice about what I can or should try next?

@SoleroTG commented on GitHub (Nov 20, 2022): Just a small update: The `emergency_access` table still shows the same content, although no emergency job being neither active no pending. Should I expect a cronjob fixing the entry? The only log entries related to this are: ``` [2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_notification_reminder_job [2022-11-20 01:05:06.664][vaultwarden::api::core::emergency_access][DEBUG] Start emergency_request_timeout_job [2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request timeout to approve [2022-11-20 01:05:06.665][vaultwarden::api::core::emergency_access][DEBUG] No emergency request reminder notification to send ``` I'm grateful for any advice about what I can or should try next?
GiteaMirror commented 2026-03-07 20:11:10 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 21, 2022):

Regarding the emergency access I am just getting the above posted entries about no emergency request being active (which is true atm).
The entry in the emergency_access table still exists.

Can I manually delete this entry?

@SoleroTG commented on GitHub (Nov 21, 2022): Regarding the emergency access I am just getting the above posted entries about no emergency request being active (which is true atm). The entry in the `emergency_access` table still exists. Can I manually delete this entry?
GiteaMirror commented 2026-03-07 20:11:11 -06:00
Author
Owner
Copy Link
Copy Source

@stefan0xC commented on GitHub (Nov 21, 2022):

Can I manually delete this entry?

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

I'm grateful for any advice about what I can or should try next?

You could try a PRAGMA integrity_check on the sqlite database.

@stefan0xC commented on GitHub (Nov 21, 2022): > Can I manually delete this entry? If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well. > I'm grateful for any advice about what I can or should try next? You could try a `PRAGMA integrity_check` on the sqlite database.
GiteaMirror commented 2026-03-07 20:11:11 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 21, 2022):

If you want to grant your self access by an already approved access, which means ot shared the keys. The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

@BlackDex commented on GitHub (Nov 21, 2022): If you want to grant your self access by an already approved access, which means ot shared the keys. The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.
GiteaMirror commented 2026-03-07 20:11:11 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 21, 2022):

If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well.

Right now, no user is shown neither as grantor nor grantee in the ui. This is consistent with my actions in the ui.

You could try a PRAGMA integrity_check on the sqlite database.

I ran the command and received integrity_check OK
The line in the emergency_access table, however, is still there.

The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault.

I changed the status in the emergency_access table from 3 to 4. This made the entry disappear in the db. Looks good so far.

Now I try again to give grantee emergency access and will post the result here.

Thanks for the help. I keep you updated.

@SoleroTG commented on GitHub (Nov 21, 2022): > If you remove the grantee as grantor (or yourself as grantee) the entry should be deleted as well. Right now, no user is shown neither as grantor nor grantee in the ui. This is consistent with my actions in the ui. > You could try a PRAGMA integrity_check on the sqlite database. I ran the command and received `integrity_check OK` The line in the `emergency_access` table, however, is still there. > The you can change the status your self too 4. Else you should also be able to remove the access on either side via the web-vault. I changed the `status` in the `emergency_access` table from 3 to 4. This made the entry disappear in the db. Looks good so far. Now I try again to give grantee emergency access and will post the result here. Thanks for the help. I keep you updated.
GiteaMirror commented 2026-03-07 20:11:12 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 22, 2022):

It worked.
After I manipulated the db directly and set the status in the emergency_access table from 3 to 4 it worked like a charm.
Although, I have no idea how this corrupt entry appeared in the first place, I am happy that it is working now.

Thanks a lot for the support.

@SoleroTG commented on GitHub (Nov 22, 2022): It worked. After I manipulated the db directly and set the status in the `emergency_access` table from `3` to `4` it worked like a charm. Although, I have no idea how this corrupt entry appeared in the first place, I am happy that it is working now. Thanks a lot for the support.
GiteaMirror commented 2026-03-07 20:11:12 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 23, 2022):

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

As a side note. While i was checking the code, i saw some small enhancements for the code handeling this. I'll see if i can optimize the code a bit and maybe i will encounter something strange that could explain this behaviour.

@BlackDex commented on GitHub (Nov 23, 2022): Was it corrupted in which sense? Only the state was wrong? Or the database had issues? As a side note. While i was checking the code, i saw some small enhancements for the code handeling this. I'll see if i can optimize the code a bit and maybe i will encounter something strange that could explain this behaviour.
GiteaMirror commented 2026-03-07 20:11:12 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 23, 2022):

I might have found something which could cause this specific issue.
There could be some race-conditions and that could cause strange behaviors.

@BlackDex commented on GitHub (Nov 23, 2022): I might have found something which could cause this specific issue. There could be some race-conditions and that could cause strange behaviors.
GiteaMirror commented 2026-03-07 20:11:13 -06:00
Author
Owner
Copy Link
Copy Source

@SoleroTG commented on GitHub (Nov 23, 2022):

Was it corrupted in which sense? Only the state was wrong? Or the database had issues?

The database itself was consistent. With the term corrupted I mean that the database was in a state in which the application didn't function correctly and wasn't able to correct itself. If the term corrupted doesn't fit here I take it back and may as well call it in a funny state.

Anyhow, thanks again for the fast support.

@SoleroTG commented on GitHub (Nov 23, 2022): > Was it corrupted in which sense? Only the state was wrong? Or the database had issues? The database itself was consistent. With the term _corrupted_ I mean that the database was in a state in which the application didn't function correctly and wasn't able to correct itself. If the term _corrupted_ doesn't fit here I take it back and may as well call it _in a funny state_. Anyhow, thanks again for the fast support.
GiteaMirror commented 2026-03-07 20:11:13 -06:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (Nov 23, 2022):

To make the terms a bit more clear. A corrupt database is a database which isn't functioning at all.
A record with an invalid state is what was causing the issue.

The reason it is important, a corrupt database could also cause some strange issue, including not being able to update a record.
But, if the database was valid, then there might be a coding issue.

As already mentioned, I think i have found what could cause this. One way of fixing this your self would be to change the schedules of the two emergency access jobs in such a way that they will never run at the same time.

I keep this issue open until i finished the changes to the emergency access code.

@BlackDex commented on GitHub (Nov 23, 2022): To make the terms a bit more clear. A corrupt database is a database which isn't functioning at all. A record with an invalid state is what was causing the issue. The reason it is important, a corrupt database could also cause some strange issue, including not being able to update a record. But, if the database was valid, then there might be a coding issue. As already mentioned, I think i have found what could cause this. One way of fixing this your self would be to change the schedules of the two emergency access jobs in such a way that they will never run at the same time. I keep this issue open until i finished the changes to the emergency access code.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
wontfix
No labels bug enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#5053