Add another user "U" (any name is fine) to the organisation (as a regular user)
Create(or use existing) collection "C" (any name is fine : in my screenshot collection is named PASSWORD_RO)
Create(or use existing) group "G" (any name is fine : in my test named GRP_RO)
4.1. Give permission of that collection "C" to the group "G" with Read Only access
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does not have direct permission on the collection "C". In other words: the permission should be configured via the group only!
Login as user "U"
5.1. Add a new entry to the collection "C", "C" is shown even if the group is in RO access
5.2 Save the entry -> Error message No rights to modify the collection
5.3 A blanck entry is created automatically with nothing inside in the user "U" vault (see screenshot)
Expected behaviour
User can't select the collection "C" with rights read only (assign by a group)
This is already working for rights directly applied on user (user can't select collection with read only access)
Actual behaviour
User "U" can select a collection "C" with rights read only (assign by a group) and create automatically a trash entry in his personnal vault
Troubleshooting data
Vaultwarden Log :
vaultwarden | [2023-02-16 10:15:48.252][request][INFO] POST /api/ciphers/create
vaultwarden | [2023-02-16 10:15:48.279][vaultwarden::api::core::ciphers][ERROR] No rights to modify the collection
vaultwarden | [2023-02-16 10:15:48.279][response][INFO] (post_ciphers_create) POST /api/ciphers/create => 400 Bad Request
Trash entry created :
Collection available list when creating entry with rights applied on groups
Collection available list when creating entry with right applied directly to user (Expected behaviour with group)
Originally created by @Misterbabou on GitHub (Feb 16, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/3249
<!--
# ###
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
<!-- Describe your issue here. -->
Read Only rights issue with Groups generating trash entry on user vault (with the groups beta feature enabled).
### Deployment environment
<!--
=========================================================================================
Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab.
That will auto-generate most of the info requested in this section.
=========================================================================================
-->
<!-- The version number, obtained from the logs (at startup) or the admin diagnostics page -->
<!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden -->
<!-- Remember to check if your issue exists on the latest version first! -->
* vaultwarden version: 1.27.0-1ba8275d
<!-- How the server was installed: Docker image, OS package, built from source, etc. -->
* Install method: Custom Built with docker with last #3108 Merge (same issue with docker vaultwarden/server:testing )
* Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> web vault
* Reverse proxy and version: <!-- if applicable --> No
* MySQL/MariaDB or PostgreSQL version: <!-- if applicable --> MariaDB 10.10.2 , Same issue with Sqlite
* Environment settings:
```
{
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": false,
"_enable_smtp": true,
"_enable_yubico": true,
"_icon_service_csp": "",
"_icon_service_url": "",
"_ip_header_enabled": true,
"_smtp_img_src": "cid:",
"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": false,
"emergency_notification_reminder_schedule": "0 3 * * * *",
"emergency_request_timeout_schedule": "0 7 * * * *",
"enable_db_wal": true,
"event_cleanup_schedule": "0 10 0 * * *",
"events_days_retain": 7,
"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": "TestSRV",
"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": true,
"password_hints_allowed": false,
"password_iterations": 600000,
"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": null,
"smtp_debug": false,
"smtp_embed_images": true,
"smtp_explicit_tls": null,
"smtp_from": "",
"smtp_from_name": "Vaultwarden",
"smtp_host": null,
"smtp_password": null,
"smtp_port": 587,
"smtp_security": "starttls",
"smtp_ssl": null,
"smtp_timeout": 15,
"smtp_username": null,
"templates_folder": "data/templates",
"tmp_folder": "data/tmp",
"trash_auto_delete_days": 15,
"trash_purge_schedule": "0 5 0 * * *",
"use_sendmail": false,
"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
<!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults)
and how did you start vaultwarden? -->
1. Create an organisation (or use existing)
2. Add another user "U" (any name is fine) to the organisation (as a regular user)
3. Create(or use existing) collection "C" (any name is fine : in my screenshot collection is named PASSWORD_RO)
4. Create(or use existing) group "G" (any name is fine : in my test named GRP_RO)
4.1. Give permission of that collection "C" to the group "G" **with Read Only access**
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does not have direct permission on the collection "C". In other words: the permission should be configured via the group only!
5. Login as user "U"
5.1. Add a new entry to the collection "C", "C" is shown even if the group is in RO access
5.2 Save the entry -> Error message `No rights to modify the collection`
5.3 A blanck entry is created automatically with nothing inside in the user "U" vault (see screenshot)
### Expected behaviour
<!-- Tell us what you expected to happen -->
User can't select the collection "C" with rights read only (assign by a group)
This is already working for rights directly applied on user (user can't select collection with read only access)
### Actual behaviour
<!-- Tell us what actually happened -->
User "U" can select a collection "C" with rights read only (assign by a group) and create automatically a trash entry in his personnal vault
### Troubleshooting data
<!-- Share any log files, screenshots, or other relevant troubleshooting data -->
- Vaultwarden Log :
```
vaultwarden | [2023-02-16 10:15:48.252][request][INFO] POST /api/ciphers/create
vaultwarden | [2023-02-16 10:15:48.279][vaultwarden::api::core::ciphers][ERROR] No rights to modify the collection
vaultwarden | [2023-02-16 10:15:48.279][response][INFO] (post_ciphers_create) POST /api/ciphers/create => 400 Bad Request
```
- Trash entry created :
- Collection available list when creating entry with rights applied on groups
- Collection available list when creating entry with right applied directly to user (Expected behaviour with group)
GiteaMirror
added the bug label 2026-07-13 19:11:04 -05:00
I modified Steps to reproduce to explain the steps better
I made new tests with those changing variable :
1 - image: vaultwarden/server:testing (last available), and MariaDB 10.10.2
2- image: vaultwarden/server:testing (last available) and Sqlite
I have still the same issue with those additional tests.
<!-- gh-comment-id:1433098217 -->
@Misterbabou commented on GitHub (Feb 16, 2023):
I modified **Steps to reproduce** to explain the steps better
I made new tests with those changing variable :
1 - image: vaultwarden/server:testing (last available), and MariaDB 10.10.2
2- image: vaultwarden/server:testing (last available) and Sqlite
I have still the same issue with those additional tests.
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 @Misterbabou on GitHub (Feb 16, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/3249
Subject of the issue
Read Only rights issue with Groups generating trash entry on user vault (with the groups beta feature enabled).
Deployment environment
Install method: Custom Built with docker with last #3108 Merge (same issue with docker vaultwarden/server:testing )
Clients used: web vault
Reverse proxy and version: No
MySQL/MariaDB or PostgreSQL version: MariaDB 10.10.2 , Same issue with Sqlite
Environment settings:
Steps to reproduce
4.1. Give permission of that collection "C" to the group "G" with Read Only access
4.2. Assign the user "U" to the group "G"
4.3. Make sure that the user "U" does not have direct permission on the collection "C". In other words: the permission should be configured via the group only!
5.1. Add a new entry to the collection "C", "C" is shown even if the group is in RO access
5.2 Save the entry -> Error message
No rights to modify the collection5.3 A blanck entry is created automatically with nothing inside in the user "U" vault (see screenshot)
Expected behaviour
User can't select the collection "C" with rights read only (assign by a group)
This is already working for rights directly applied on user (user can't select collection with read only access)
Actual behaviour
User "U" can select a collection "C" with rights read only (assign by a group) and create automatically a trash entry in his personnal vault
Troubleshooting data
Trash entry created :
Collection available list when creating entry with rights applied on groups
Collection available list when creating entry with right applied directly to user (Expected behaviour with group)
@Misterbabou commented on GitHub (Feb 16, 2023):
I modified Steps to reproduce to explain the steps better
I made new tests with those changing variable :
1 - image: vaultwarden/server:testing (last available), and MariaDB 10.10.2
2- image: vaultwarden/server:testing (last available) and Sqlite
I have still the same issue with those additional tests.