[GH-ISSUE #5711] Collections permission issue in organisation

kerem commented

2026-03-03 02:16:27 +03:00

Owner

Originally created by @MattiasH97 on GitHub (Mar 19, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5711

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.33.2
Web-vault version: v2025.1.1
OS/Arch: linux/x86_64
Running within a container: true (Base: Debian)
Database type: SQLite
Database version: 3.48.0
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
Browser/Server Time Check: true
Server/NTP Time Check: n/a
Domain Configuration Check: true
HTTPS Check: true
Websocket Check: true
HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: ADMIN_TOKEN

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "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_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "fido2-vault-credentials",
  "extended_logging": true,
  "helo_name": "*****************",
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": 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": 6,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "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": "",
  "org_events_enabled": false,
  "org_groups_enabled": false,
  "password_hints_allowed": false,
  "password_iterations": 600000,
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "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": "Login",
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*****************",
  "smtp_from_name": "Compliq Password Manager",
  "smtp_host": "*****************",
  "smtp_password": "***",
  "smtp_port": 25,
  "smtp_security": "starttls",
  "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_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Vaultwarden Build Version

v.1.33.2

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

Nginx Proxy Manager, v2.12

Host/Server Operating System

Linux

Operating System Version

Windows 11

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Go to admin console
Click on collections in the left tab
Mark a few collections, the more you mark the more likely it happens. It listed
Press the top right triple dot
Press edit access
Add user with the permission and save

Expected Result

User will be added to the collection while maintaining current permissions as we have not touched it.

Actual Result

User will be added to the collection but clears out all other users access to those collections.

Logs

Screenshots or Videos

No response

Additional Context

Backstory
One of my colleagues had done a big oopsie and added his MFA TOTP for vaultwarden into vaultwarden... He got locked out and suddenly had no way to verify his account. Trust me, he got chastised for using vaultwarden to authenticate vaultwarden.

We revoked his 2fa so that he could login and get setup again. For the organisation he had admin permissions so he could see and manage all collections. Due to 2fa being required his account automatically had his access revoked to the organisation. I went and restored access to the organisation. So far everything behaves as one would expect but soon trails off.

Once his account was back he had user permission without any collections and once I gave him admin again he still did not get any of the collections. The odd part is when I tested giving him manual access to the collections that worked... but for whatever god forsaken reason it decided to remove everyone else's collection access.. for all users.. and I can't for the life of me understand why.
Thankfully we only have a handful of users and I got a very good grasp on what they had access to, but I was able to replicate the issue when I tried to give another user access to all collections manually. Then it reset the collections I had just fixed the permissions for again.

As a whole the system has worked great and honestly this is the first time we have run into any issues besides a few client errors when we pull a new image which have always been resolved by simply updating the client.

As of writing the steps to reproduce I might have figured out what is causing it but wanted it out there in case this is an unexpected behaviour.
I believe it is that it lists no users when you have multiple collections with different user permission. Let's say User A has access to collection 1, 2 and 3, while user B only has collection 2. It lists 0 users in the collection and instead of adding user C to the collections you listed, it will become an absolute value. User C has access to the collections listed and then removing the rest.
Not sure if it is me misunderstanding it when it said "No members added" at the time but I believe this is what happens.

We still have an issue with him not getting access automatically to the collections as admin nor owner.

Originally created by @MattiasH97 on GitHub (Mar 19, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5711 ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.33.2 * Web-vault version: v2025.1.1 * OS/Arch: linux/x86_64 * Running within a container: true (Base: Debian) * Database type: SQLite * Database version: 3.48.0 * 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 * Browser/Server Time Check: true * Server/NTP Time Check: n/a * Domain Configuration Check: true * HTTPS Check: true * Websocket Check: true * HTTP Response Checks: true ### Config & Details (Generated via diagnostics page) <details><summary>Show Config & Details</summary> **Environment settings which are overridden:** ADMIN_TOKEN **Config:** ```json { "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "***:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_connect_src": "", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "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_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "experimental_client_feature_flags": "fido2-vault-credentials", "extended_logging": true, "helo_name": "*****************", "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": 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": 6, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "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": "", "org_events_enabled": false, "org_groups_enabled": false, "password_hints_allowed": false, "password_iterations": 600000, "push_enabled": false, "push_identity_uri": "https://identity.bitwarden.com", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "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": "Login", "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*****************", "smtp_from_name": "Compliq Password Manager", "smtp_host": "*****************", "smtp_password": "***", "smtp_port": 25, "smtp_security": "starttls", "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_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Vaultwarden Build Version v.1.33.2 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy Nginx Proxy Manager, v2.12 ### Host/Server Operating System Linux ### Operating System Version Windows 11 ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce 1. Go to admin console 2. Click on collections in the left tab 3. Mark a few collections, the more you mark the more likely it happens. It listed 4. Press the top right triple dot 5. Press edit access 6. Add user with the permission and save ### Expected Result User will be added to the collection while maintaining current permissions as we have not touched it. ### Actual Result User will be added to the collection but clears out all other users access to those collections. ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context **Backstory** One of my colleagues had done a big oopsie and added his MFA TOTP for vaultwarden into vaultwarden... He got locked out and suddenly had no way to verify his account. Trust me, he got chastised for using vaultwarden to authenticate vaultwarden. We revoked his 2fa so that he could login and get setup again. For the organisation he had admin permissions so he could see and manage all collections. Due to 2fa being required his account automatically had his access revoked to the organisation. I went and restored access to the organisation. So far everything behaves as one would expect but soon trails off. Once his account was back he had user permission without any collections and once I gave him admin again he still did not get any of the collections. The odd part is when I tested giving him manual access to the collections that worked... but for whatever god forsaken reason it decided to remove everyone else's collection access.. for all users.. and I can't for the life of me understand why. Thankfully we only have a handful of users and I got a very good grasp on what they had access to, but I was able to replicate the issue when I tried to give another user access to all collections manually. Then it reset the collections I had just fixed the permissions for again. As a whole the system has worked great and honestly this is the first time we have run into any issues besides a few client errors when we pull a new image which have always been resolved by simply updating the client. ----------- As of writing the steps to reproduce I might have figured out what is causing it but wanted it out there in case this is an unexpected behaviour. I believe it is that it lists no users when you have multiple collections with different user permission. Let's say User A has access to collection 1, 2 and 3, while user B only has collection 2. It lists 0 users in the collection and instead of adding user C to the collections you listed, it will become an absolute value. User C has access to the collections listed and then removing the rest. Not sure if it is me misunderstanding it when it said "No members added" at the time but I believe this is what happens. We still have an issue with him not getting access automatically to the collections as admin nor owner.

kerem

2026-03-03 02:16:27 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@JIinfrastructure commented on GitHub (Mar 20, 2025):

same issue here. also version 1.33.2

@JIinfrastructure commented on GitHub (Mar 20, 2025): same issue here. also version 1.33.2

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@MattiasH97 commented on GitHub (Mar 21, 2025):

When testing today, even when I select only one collection and then manage access, it does not list any members even though I know that is not true.
Meaning if I were to 'add' a user to the list, I would nuke the permission for that collection.

@MattiasH97 commented on GitHub (Mar 21, 2025): When testing today, even when I select only one collection and then manage access, it does not list any members even though I know that is not true. Meaning if I were to 'add' a user to the list, I would nuke the permission for that collection.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@MattiasH97 commented on GitHub (Mar 21, 2025):

I have very fat fingers... this is not solved and I can't re-open

@MattiasH97 commented on GitHub (Mar 21, 2025): I have very fat fingers... this is not solved and I can't re-open

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@Erik-Hoffmann commented on GitHub (Mar 24, 2025):

We have the same issue, also using 1.33.2.

@Erik-Hoffmann commented on GitHub (Mar 24, 2025): We have the same issue, also using 1.33.2.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@Timshel commented on GitHub (Mar 24, 2025):

For the admin role not granting access to all collections I believe https://github.com/dani-garcia/vaultwarden/pull/5673 should fix it.

@Timshel commented on GitHub (Mar 24, 2025): For the admin role not granting access to all collections I believe https://github.com/dani-garcia/vaultwarden/pull/5673 should fix it.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@mediocricity commented on GitHub (Apr 15, 2025):

Hey there, are there updates on this? This issue is greatly affecting our productivity since our devs keep getting locked out.

@mediocricity commented on GitHub (Apr 15, 2025): Hey there, are there updates on this? This issue is greatly affecting our productivity since our devs keep getting locked out.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@BlackDex commented on GitHub (Apr 15, 2025):

In what sense? How is creating a group which has collection access for these devs, and assigning these groups not working right now?

@BlackDex commented on GitHub (Apr 15, 2025): In what sense? How is creating a group which has collection access for these devs, and assigning these groups not working right now?

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@BlackDex commented on GitHub (Apr 15, 2025):

Also, the PR #5673 might solve the issue in a quick way. But in the end, the access_all feature should be removed, as this is just not how Bitwarden works anymore and support for this way of working will be difficult in the future with all the separate rolls and collection/group permissions they are using now.

@BlackDex commented on GitHub (Apr 15, 2025): Also, the PR #5673 might solve the issue in a quick way. But in the end, the `access_all` feature should be removed, as this is just not how Bitwarden works anymore and support for this way of working will be difficult in the future with all the separate rolls and collection/group permissions they are using now.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@otbutz commented on GitHub (Apr 15, 2025):

In what sense? How is creating a group which has collection access for these devs, and assigning these groups not working right now?

I guess because most users are unaware that this is possible? (me included up until right now) 😅
The beta status paired with the known issues warning isn't helping either.

github.com/dani-garcia/vaultwarden@66cf179bca/.env.template (L432-L437)

If the groups feature is enabled by default, the whole issue here becomes a nothing burger.

@otbutz commented on GitHub (Apr 15, 2025): > In what sense? How is creating a group which has collection access for these devs, and assigning these groups not working right now? I guess because most users are unaware that this is possible? (me included up until right now) 😅 The beta status paired with the known issues warning isn't helping either. https://github.com/dani-garcia/vaultwarden/blob/66cf179bca3955d1776a5a9e48f4249e1af0bfb1/.env.template#L432-L437 If the groups feature is enabled by default, the whole issue here becomes a nothing burger.

kerem commented

2026-03-03 02:16:29 +03:00

Author

Owner

@BlackDex commented on GitHub (Apr 15, 2025):

That might be a good one for the next release, since it now makes it easier to manage everything.

@BlackDex commented on GitHub (Apr 15, 2025): That might be a good one for the next release, since it now makes it easier to manage everything.

Rows
Columns

[GH-ISSUE #5711] Collections permission issue in organisation #2227

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Config & Details (Generated via diagnostics page)

Vaultwarden Build Version

Deployment method

Custom deployment method

Reverse Proxy

Host/Server Operating System

Operating System Version

Clients

Client Version

Steps To Reproduce

Expected Result

Actual Result

Logs

Screenshots or Videos

Additional Context