Manager can't move PWs in between Shares

The cause of the error is probably the “group function” which is still experimental. There is no solution (unless you assign the rights 1:1 to the user instead of the group). I am following the fix #3624 Fix #3624: fix manager permission within groups by matlink · Pull Request #3754 · dani-garcia/vaultwarden (

Hy guys,
my first time and with an error which i cant solve by myself… hope i find here an solution.

I have the following error:

User: Manager role (with rights to required collections)
Interface: Web & Bitwarden app
Password: The password is contained in 2 collections.
Error: Manager wants to remove a password from a collection - so that it is only visible in one collection.

  1. click on the 3-dot menu button
  2. select "Collections
  3. removes the checkmark from the unwanted collection
  4. press Save - (The feedback is “Saved” and the password disappears from the unwanted collection.
  5. refresh the page, log out (or whatever triggers a refresh) the changes have not been applied as the password is back in both collections.

Info: If I do the procedure with an “Administrator” account - this error does not occur.

I have looked at similar posts but could not find a solution. That worked.

My environment:

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.30.3
  • Web-vault version: v2024.1.2
  • OS/Arch: linux/x86_64
  • 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
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: SQLite
  • Database version: 3.44.0
  • Clients used:
  • Reverse proxy and version:
  • Other relevant information:

Can you provide the vaultwarden logs when this occurs?

here are the logs… cant find any “error”. But i think that the log-level is to soft to catch the information.

During the short time span (2min) I did the process with a manager and then with the administrator. Personally, I see no difference.

[2024-02-21 11:45:52.361][request][INFO] PUT /api/ciphers/057f3fbd-801d-434e-83d4-fa234bf997a4/collections
[2024-02-21 11:45:52.388][response][INFO] (put_collections_update) PUT /api/ciphers//collections => 200 OK
[2024-02-21 11:45:52.436][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/collections/details
[2024-02-21 11:45:52.438][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/groups
[2024-02-21 11:45:52.439][response][INFO] (get_org_collections_details) GET /api/organizations/<org_id>/collections/details => 200 OK
[2024-02-21 11:45:52.440][response][INFO] (get_groups) GET /api/organizations/<org_id>/groups => 200 OK
[2024-02-21 11:45:52.444][request][INFO] GET /api/ciphers/057f3fbd-801d-434e-83d4-fa234bf997a4/details
[2024-02-21 11:45:52.445][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:45:52.724][request][INFO] GET /api/ciphers/057f3fbd-801d-434e-83d4-fa234bf997a4/details
[2024-02-21 11:45:52.725][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:45:53.308][request][INFO] GET /api/ciphers/057f3fbd-801d-434e-83d4-fa234bf997a4/details
[2024-02-21 11:45:53.308][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:45:54.608][request][INFO] GET /api/config
[2024-02-21 11:45:54.608][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 11:45:54.989][request][INFO] GET /icons/
[2024-02-21 11:45:54.989][request][INFO] GET /icons/
[2024-02-21 11:45:54.990][request][INFO] GET /icons/
[2024-02-21 11:45:54.990][response][INFO] (icon_internal) GET /icons//icon.png => 200 OK
[2024-02-21 11:45:54.990][response][INFO] (icon_internal) GET /icons//icon.png => 200 OK
[2024-02-21 11:45:54.991][response][INFO] (icon_internal) GET /icons//icon.png => 200 OK
[2024-02-21 11:45:55.066][request][INFO] GET /api/config
[2024-02-21 11:45:55.067][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 11:45:56.502][request][INFO] GET /api/accounts/revision-date
[2024-02-21 11:45:56.502][response][INFO] (revision_date) GET /api/accounts/revision-date => 200 OK
[2024-02-21 11:45:56.529][request][INFO] POST /identity/connect/token
[2024-02-21 11:45:56.530][response][INFO] (login) POST /identity/connect/token => 200 OK
[2024-02-21 11:45:56.545][request][INFO] GET /api/sync?excludeDomains=true
[2024-02-21 11:45:56.623][response][INFO] (sync) GET /api/sync?<data…> => 200 OK
[2024-02-21 11:45:56.802][request][INFO] GET /api/config
[2024-02-21 11:45:56.802][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 11:46:22.266][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/collections/details
[2024-02-21 11:46:22.266][request][INFO] GET /api/ciphers/organization-details?organizationId=d520931f-aa54-4
[2024-02-21 11:46:22.266][request][INFO] GET /api/ciphers/organization-details?organizationId=d520931f-aa54-4
[2024-02-21 11:46:22.267][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/groups
[2024-02-21 11:46:22.271][response][INFO] (get_org_collections_details) GET /api/organizations/<org_id>/collections/details => 200 OK
[2024-02-21 11:46:22.273][response][INFO] (get_groups) GET /api/organizations/<org_id>/groups => 200 OK
[2024-02-21 11:46:22.800][response][INFO] (get_org_details) GET /api/ciphers/organization-details?<data…> => 200 OK
[2024-02-21 11:46:22.872][response][INFO] (get_org_details) GET /api/ciphers/organization-details?<data…> => 200 OK
[2024-02-21 11:46:36.164][request][INFO] GET /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/admin
[2024-02-21 11:46:36.165][response][INFO] (get_cipher_admin) GET /api/ciphers//admin => 200 OK
[2024-02-21 11:46:42.273][request][INFO] GET /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/admin
[2024-02-21 11:46:42.274][response][INFO] (get_cipher_admin) GET /api/ciphers//admin => 200 OK
[2024-02-21 11:46:44.042][request][INFO] PUT /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/collections-admin
[2024-02-21 11:46:44.044][response][INFO] (put_collections_admin) PUT /api/ciphers//collections-admin => 200 OK
[2024-02-21 11:46:44.052][request][INFO] GET /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/details
[2024-02-21 11:46:44.053][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:46:44.056][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/collections/details
[2024-02-21 11:46:44.056][request][INFO] GET /api/organizations/d520931f-aa54-4f3d-9fa1-482a642c355c/groups
[2024-02-21 11:46:44.056][request][INFO] GET /api/ciphers/organization-details?organizationId=d520931f-aa54-4
[2024-02-21 11:46:44.058][response][INFO] (get_groups) GET /api/organizations/<org_id>/groups => 200 OK
[2024-02-21 11:46:44.058][response][INFO] (get_org_collections_details) GET /api/organizations/<org_id>/collections/details => 200 OK
[2024-02-21 11:46:44.090][request][INFO] GET /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/details
[2024-02-21 11:46:44.091][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:46:44.170][request][INFO] GET /api/ciphers/e05015fb-6b28-4b77-a6b7-94c91684be9f/details
[2024-02-21 11:46:44.171][response][INFO] (get_cipher_details) GET /api/ciphers//details => 200 OK
[2024-02-21 11:46:44.489][request][INFO] GET /api/config
[2024-02-21 11:46:44.490][response][INFO] (config) GET /api/config => 200 OK
[2024-02-21 11:46:44.611][response][INFO] (get_org_details) GET /api/ciphers/organization-details?<data…> => 200 OK
[2024-02-21 11:46:46.718][request][INFO] GET /icons/
[2024-02-21 11:46:46.718][request][INFO] GET /icons/

It probably is related to this open issue

This sounds similar - but has a different error pattern.

I have the editing option and the change is applied locally (the password disappears from the collection, which is also checked). But on refresh (in the web log: “decryption is done”) the change is undone. Almost as if the change was not transferred to the server… (just cant prove my take)

Danke für die Zeit / thanks for your time

Yeah, I mean it’s a bit hard to debug client errors and find out what causes them (but since we have this open issue I rather would assume that the fault lies with the data we send instead of the a bug in the client itself. So this bug might be resolved by the linked pr or it might not and we have to address the issue on its own - either way that’s why we consider the feature still experimental).
You can look in the browser console and check the network requests that are sent or if there are any exceptions thrown by the client.

You were right with your statement
My fault pattern is different BUT the cause is probably the same. If I take over the rights 1:1 and transfer them to the user (instead of the group) - the error no longer occurs.

I was hoping that the “group function” would not have any errors that would affect me :^) - sad life.

In short - I’m following the fix #3624 and hoping for the best ~thanks