Database version: PostgreSQL 14.19 (Debian 14.19-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
Uses config.json: false
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: true
Domain Configuration Check: true
HTTPS Check: true
Websocket Check: true
HTTP Response Checks: false
Config & Details (Generated via diagnostics page)
Show Config & Details
Failed HTTP Checks:
API calls:Header:'x-frame-options'does not contain 'SAMEORIGIN'Header:'x-xss-protection'does not contain '0'2FA Connector calls:Header:'x-xss-protection'does not contain '0'Header:'x-frame-options'is present while it should not
Subject of the Issue.
When attempting to change a user's collection permission from Manage collection to Edit items via the Web UI, the change does not persist. The permission automatically reverts to Manage collection upon saving, despite the application displaying a success message. Other permission changes work as expected.
Steps to Reproduce.
Log in to the Vaultwarden Admin Panel.
Navigate to the Members section and select a user who currently has the Manage collection permission for a specific collection.
Go to the Collections tab for that user.
Click the dropdown menu for the collection's permission and select Edit items.
Click the Save button.
Expected Result
Expected Behavior.
The user's permission for the selected collection should be updated to Edit items. When returning to the user's settings, the dropdown should reflect the new, lower-level permission.
Actual Result
Observed Behavior.
After clicking Save, a success message, "Edited user [user email]," is displayed.
However, when the page is reloaded or the user's settings are revisited, the permission for the collection is still set to Manage collection.
This behavior is specific to downgrading to the Edit items permission. Other permission changes (e.g., from View to Manage) function as intended.
The server's event log also confirms a successful Edited user event, indicating the issue is not a failure to save, but rather an incorrect value being saved.
Logs
Screenshots or Videos
No response
Additional Context
Troubleshooting Performed.
Attempted to downgrade the permission directly through the Web UI multiple times.
Completely removed the user from the collection, saved the changes, and then re-added them with the Edit items permission. The permission still defaulted to Manage collection upon saving.
Restarted the Vaultwarden Docker container/service.
Originally created by @captainloogie on GitHub (Aug 19, 2025).
### Prerequisites
- [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=)
- [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/)
### 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 14.19 (Debian 14.19-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
* Uses config.json: false
* 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: true
* Domain Configuration Check: true
* HTTPS Check: true
* Websocket Check: true
* HTTP Response Checks: false
### Config & Details (Generated via diagnostics page)
<details><summary>Show Config & Details</summary>
**Failed HTTP Checks:**
```yaml
API calls:
Header: 'x-frame-options' does not contain 'SAMEORIGIN'
Header: 'x-xss-protection' does not contain '0'
2FA Connector calls:
Header: 'x-xss-protection' does not contain '0'
Header: 'x-frame-options' is present while it should not
```
**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": false,
"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": "",
"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": "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": 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": 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": 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": "***",
"smtp_port": 587,
"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
1.34.3
### Deployment method
Official Container Image
### Custom deployment method
_No response_
### Reverse Proxy
nginx
### Host/Server Operating System
Linux
### Operating System Version
Ubuntu 24.04
### Clients
Desktop
### Client Version
Chrome 139.0.7258.67 (Official Build) (64-bit)
### Steps To Reproduce
Subject of the Issue.
When attempting to change a user's collection permission from Manage collection to Edit items via the Web UI, the change does not persist. The permission automatically reverts to Manage collection upon saving, despite the application displaying a success message. Other permission changes work as expected.
Steps to Reproduce.
Log in to the Vaultwarden Admin Panel.
Navigate to the Members section and select a user who currently has the Manage collection permission for a specific collection.
Go to the Collections tab for that user.
Click the dropdown menu for the collection's permission and select Edit items.
Click the Save button.
### Expected Result
Expected Behavior.
The user's permission for the selected collection should be updated to Edit items. When returning to the user's settings, the dropdown should reflect the new, lower-level permission.
### Actual Result
Observed Behavior.
After clicking Save, a success message, "Edited user [user email]," is displayed.
However, when the page is reloaded or the user's settings are revisited, the permission for the collection is still set to Manage collection.
This behavior is specific to downgrading to the Edit items permission. Other permission changes (e.g., from View to Manage) function as intended.
The server's event log also confirms a successful Edited user event, indicating the issue is not a failure to save, but rather an incorrect value being saved.
### Logs
```text
```
### Screenshots or Videos
_No response_
### Additional Context
Troubleshooting Performed.
Attempted to downgrade the permission directly through the Web UI multiple times.
Completely removed the user from the collection, saved the changes, and then re-added them with the Edit items permission. The permission still defaulted to Manage collection upon saving.
Restarted the Vaultwarden Docker container/service.
GiteaMirror
added the bug label 2026-03-07 20:46:41 -06:00
Vaultwarden does not support fine-grained permissions (yet), and we currently abuse some way of working to keep the old manager role active. This does mean we in some situations we modify the Edit and Can Manage according to the user's role and rights.
Therefor this sometimes looks like invalid or weird. There also isn't anything useful we can return to indicate we abuse this in some way. It's either an error or a simple ok.
Since this is a works-as-intended, I'm going to close this.
@BlackDex commented on GitHub (Aug 19, 2025):
Vaultwarden does not support fine-grained permissions (yet), and we currently abuse some way of working to keep the old manager role active. This does mean we in some situations we modify the `Edit` and `Can Manage` according to the user's role and rights.
Therefor this sometimes looks like invalid or weird. There also isn't anything useful we can return to indicate we abuse this in some way. It's either an error or a simple ok.
Since this is a works-as-intended, I'm going to close this.
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 @captainloogie on GitHub (Aug 19, 2025).
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Failed HTTP Checks:
Config:
Vaultwarden Build Version
1.34.3
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
nginx
Host/Server Operating System
Linux
Operating System Version
Ubuntu 24.04
Clients
Desktop
Client Version
Chrome 139.0.7258.67 (Official Build) (64-bit)
Steps To Reproduce
Subject of the Issue.
When attempting to change a user's collection permission from Manage collection to Edit items via the Web UI, the change does not persist. The permission automatically reverts to Manage collection upon saving, despite the application displaying a success message. Other permission changes work as expected.
Steps to Reproduce.
Log in to the Vaultwarden Admin Panel.
Navigate to the Members section and select a user who currently has the Manage collection permission for a specific collection.
Go to the Collections tab for that user.
Click the dropdown menu for the collection's permission and select Edit items.
Click the Save button.
Expected Result
Expected Behavior.
The user's permission for the selected collection should be updated to Edit items. When returning to the user's settings, the dropdown should reflect the new, lower-level permission.
Actual Result
Observed Behavior.
After clicking Save, a success message, "Edited user [user email]," is displayed.
However, when the page is reloaded or the user's settings are revisited, the permission for the collection is still set to Manage collection.
This behavior is specific to downgrading to the Edit items permission. Other permission changes (e.g., from View to Manage) function as intended.
The server's event log also confirms a successful Edited user event, indicating the issue is not a failure to save, but rather an incorrect value being saved.
Logs
Screenshots or Videos
No response
Additional Context
Troubleshooting Performed.
Attempted to downgrade the permission directly through the Web UI multiple times.
Completely removed the user from the collection, saved the changes, and then re-added them with the Edit items permission. The permission still defaulted to Manage collection upon saving.
Restarted the Vaultwarden Docker container/service.
@BlackDex commented on GitHub (Aug 19, 2025):
Vaultwarden does not support fine-grained permissions (yet), and we currently abuse some way of working to keep the old manager role active. This does mean we in some situations we modify the
EditandCan Manageaccording to the user's role and rights.Therefor this sometimes looks like invalid or weird. There also isn't anything useful we can return to indicate we abuse this in some way. It's either an error or a simple ok.
Since this is a works-as-intended, I'm going to close this.