User collection permissions not showing in admin console and Manager/Custom role cannot edit

[dwestness]

Prerequisites

• I have searched the existing Closed AND Open Issues AND Discussions
• I have searched and read the documentation

Vaultwarden Support String

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.34.3
• Web-vault version: v2025.7.0
• OS/Arch: linux/x86_64
• Running within a container: true (Base: Debian)
• Database type: PostgreSQL
• Database version: PostgreSQL 15.13 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit
• Uses config.json: true
• Uses a reverse proxy: true
• IP Header check: true (X-Forwarded-For)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• TZ environment: America/Detroit
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• 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: DOMAIN, SENDS_ALLOWED, TRASH_AUTO_DELETE_DAYS, SIGNUPS_ALLOWED, SIGNUPS_VERIFY, SIGNUPS_DOMAINS_WHITELIST, ORG_CREATION_USERS, INVITATION_ORG_NAME, IP_HEADER, DISABLE_2FA_REMEMBER, REQUIRE_DEVICE_EMAIL, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY, SMTP_HOST, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, _ENABLE_EMAIL_2FA

Config:

{
  "_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,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": null,
  "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": true,
  "disable_admin_token": true,
  "disable_icon_download": true,
  "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": false,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": 180,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "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": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "North",
  "invitations_allowed": true,
  "ip_header": "X-Forwarded-For",
  "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": true,
  "org_groups_enabled": false,
  "password_hints_allowed": true,
  "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": true,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": false,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": true,
  "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_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*****************************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "*********************",
  "smtp_password": null,
  "smtp_port": 25,
  "smtp_security": "off",
  "smtp_ssl": false,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 180,
  "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": "56036",
  "yubico_secret_key": "***",
  "yubico_server": null
}

Vaultwarden Build Version

v1.34.3

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

GCP Application Load Balancer

Host/Server Operating System

Linux

Operating System Version

No response

Clients

Web Vault

Client Version

2025.7.0

Steps To Reproduce

1.) Go to the Admin Console
2.) Select the Organization
3.) Navigate to the Members Page
4.) Review the list of users
5.) See that some (not all) users have the User role and no collections in scope for their access, however they were previously granted access to certain collections, which they can continue to access without issue despite the collections not appearing under their user in the admin console
6.) Secondarily, if a Manager (Custom Role) attempts to edit a user in this state to add a collection to the user the web console doesn't take the change. It does not error or present any issue. It just allows the change to be saved, but it doesn't actually work and does not reflect any collections still in the admin console
7.) If an Admin/Owner performs the same operations as outlined in the above step to edit the collections for a user in this state it all works fine and the user now is properly reflecting the correct collections.

Expected Result

The Admin Console should show the collections a user has access to when delegated specific collections

Actual Result

Some users are showing no collections despite having access to specific collections.
Manager role (Custom) is unable to make changes to users while in this state
Admin/Owner role can make changes to the collections of these users and once this step is performed, then the Manager role can once again manage the user's collection as expected

Logs

This appears to be the only relevant log related to the event

[2025-10-10 08:22:52.947][request][INFO] PUT /api/organizations/65188d2e-b76e-40bc-ba14-35886d7e817f/collections/0142f33a-f05e-418a-8fce-61db7e6ab118

Screenshots or Videos

No response

Additional Context

We recently updated to version 1.34.3
We also recently moved from SQLite to postgresQL following the migration guide.

I am unsure at what point this issue manifested with these two changes.

[BlackDex]

Can you provide detailed step-by-step on how you configure a collection and then a user to a collection and what you expect to happen so that we can try and follow the exact same steps and maybe provide better information.

[dwestness]

I cannot reproduce it with new users and collections. This issue seems to have only manifested recently for some existing users. We recently not only updated to 1.34.3, but also in the same week migrated from SQLite to postgres, so my best guess is that something got messed up in DB with some records perhaps? I cannot put my finger on it though.

That being said, I will do my best to demonstrate the scenario (Ideally i could just make a video demonstration as the most effective means of showing the behavior, but i do not want to place a video out here in a public forum that will show my employee usernames and emails in context and i haven't the skill to do advanced video editing to mask that kind of detail out. If there was a more secure fashion in which i could submit a video demonstration without exposing things on the public internet, that would be great. In the interim, I will attempt some screenshots.

This is with the "Manager" (Custom) role:
First i go to the admin console and select "Edit access" on a collection:

Then i select the member of my org that i want to add to the collection like this:

I confirm they appear in the list now and press save:

The web-ui displayed this popup:

If i go back into edit access for the collection again, The user is still not reflected on the access list and i can re-add them again and again with no actual change.

If i follow these same steps with Admin/Owner access then the change does work. This specific behavior only occurs under the Manager (Custom) role.

We can also see here in the admin console that this same user shows no collections and is in the user role:

Despite the Admin console showing no collection access for this user... We do know that they do have access to the "AWSTeam" collection in this example. They can see it and access items in there.. They were granted access to it long ago and work in the collection routinely. Even the event logs show them accessing items in this collection currently despite no access to it being reflected in the admin console

[stefan0xC]

Could it be that this user still has the access_all flag set to true?

SELECT access_all FROM users_organizations
    WHERE user_uuid = (SELECT uuid FROM users WHERE email = 'usersemail@example.com')
    AND org_uuid = (SELECT uuid FROM organizations WHERE name = 'AWS Team');

edit: If you edit the user with an admin/owner account this will be set to false so that would explain why this would work afterwards. (Just adding a collection in the collection access menu would not work if that flag had been set to true as far as I've tested it.)

[dwestness]

@stefan0xC It appears you are correct. Was this option supposed to be deprecated? Why would this no longer be visible in the admin console?

access_all

true

[stefan0xC]

Yep, it was deprecated in the client but there is no migration so this is a bit hidden and leads to unexpected behavior because you can't see the flag anymore. It would probably be better if this would be either ignored for users or if we gave users with that flag access to all collections via a migration (or disabe the flag for users).

[dwestness]

Thanks for the insights. At least this provides an explanation to the behavior we are seeing. If a course correction could be handled via a migration that would be great, otherwise at least i have a list i can work on to proactively correct each user manually if i desire. Very helpful. Thank you

[dwestness]

I used this query to identify all "User" types in my instance that had this flag set

SELECT 
  organizations.name,
  users.email,users_organizations.access_all,users_organizations.status,users_organizations.atype
FROM users_organizations
LEFT JOIN users ON users_organizations.user_uuid = users.uuid 
LEFT JOIN organizations ON users_organizations.org_uuid = organizations.uuid
WHERE users_organizations.access_all = true AND users_organizations.atype = 2
ORDER BY organizations.name,users.email

In my case, there were only 6 users that matched across our orgs. I was able to go edit each one manually in the web-ui and now we are all set.

Interestingly users with the Custom role still have the visible "Manage All collections" checkbox in the UI. Since this is still manageable in the UI, I left those alone (akey = 3)

[BlackDex]

I'm not sure what the best solution would be here. I hope someone is bold enough to rewrite the whole rbac stuff haha