[GH-ISSUE #1079] Entries not showing up in trash bin after deletion #763

New issue

Closed

opened 2026-03-03 02:02:58 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:02:58 +03:00

Owner

Originally created by @Sazzels on GitHub (Aug 2, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1079

Subject of the issue

When i delete entries from any client Windows, Android or WebUI the so deleted entry is not showing up in the trash bin.
In the WebUI a reload has to be performed and the clients need to be resynced to show trash bin entries.

Your environment

Bitwarden_rs version: docker container bitwardenrs:latest (bitwarden_rs 1.16.1)
Install method: docker-compose / nginx reverse proxy
Clients used: Windows 1.19.0 (1.20.0 has a bug which doens't allow unlocking - forces re-login), WebUI 2.15.1, Android 2.5.0
Reverse proxy and version: nginx version: nginx/1.14.2
Version of mysql/postgresql: sqlite3
Other relevant information:

Steps to reproduce

Docker Compose

version: '3'
services:
  bitwarden:
    image: 'bitwardenrs/server:latest'
    container_name: bitwarden
    hostname: bw.DOMAIN
    restart: always
    environment:
      - DOMAIN=DOMAIN
      # Timezone
      - TZ=Europe/Berlin
      # User Registration
      - SIGNUPS_ALLOWED=false
      # Admin Access
      # - ADMIN_TOKEN=ADMIN_TOKEN
      # Websocket
      - WEBSOCKET_ENABLED=true
      # SMTP
      ...
    ports:
      - '127.0.0.1:8082:80'
      - '3012:3012'
    volumes:
      - '/home/bitwarden/data:/data/'

nginx.conf (aka. bitwarden.conf)

server {
    listen         80;
    server_name    bw.DOMAIN
    return         301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bw.DOMAIN
  
    ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;

    access_log  /var/log/nginx/bitwarden-access.log;
    error_log   /var/log/nginx/bitwarden-error.log;

    client_max_body_size 128M;

    location / {
        proxy_pass http://127.0.0.1:8082;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
  
    location /notifications/hub {
        proxy_pass http://127.0.0.1:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
  
    location /notifications/hub/negotiate {
        proxy_pass http://127.0.0.1:8082;
    }
}

Expected behaviour

Deleted entries are moved to trash bin and this action is distributed to all clients like when an entrie is created / edited.

Actual behaviour

Entries are deleted correctly but not moved to the trash bin - all clients get information about deleted entry (they're removed from the group/folder) but not moved to trash bin

Relevant logs

None.

Originally created by @Sazzels on GitHub (Aug 2, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1079 ### Subject of the issue When i delete entries from any client Windows, Android or WebUI the so deleted entry is not showing up in the trash bin. In the WebUI a reload has to be performed and the clients need to be resynced to show trash bin entries. ### Your environment * Bitwarden_rs version: docker container bitwardenrs:latest (bitwarden_rs 1.16.1) * Install method: docker-compose / nginx reverse proxy * Clients used: Windows 1.19.0 (1.20.0 has a bug which doens't allow unlocking - forces re-login), WebUI 2.15.1, Android 2.5.0 * Reverse proxy and version: nginx version: nginx/1.14.2 * Version of mysql/postgresql: sqlite3 * Other relevant information: ### Steps to reproduce  *Docker Compose* ``` version: '3' services: bitwarden: image: 'bitwardenrs/server:latest' container_name: bitwarden hostname: bw.DOMAIN restart: always environment: - DOMAIN=DOMAIN # Timezone - TZ=Europe/Berlin # User Registration - SIGNUPS_ALLOWED=false # Admin Access # - ADMIN_TOKEN=ADMIN_TOKEN # Websocket - WEBSOCKET_ENABLED=true # SMTP ... ports: - '127.0.0.1:8082:80' - '3012:3012' volumes: - '/home/bitwarden/data:/data/' ``` *nginx.conf (aka. bitwarden.conf)* ``` server { listen 80; server_name bw.DOMAIN return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name bw.DOMAIN ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem; access_log /var/log/nginx/bitwarden-access.log; error_log /var/log/nginx/bitwarden-error.log; client_max_body_size 128M; location / { proxy_pass http://127.0.0.1:8082; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { proxy_pass http://127.0.0.1:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://127.0.0.1:8082; } } ``` ### Expected behaviour Deleted entries are moved to trash bin and this action is distributed to all clients like when an entrie is created / edited. ### Actual behaviour Entries are deleted correctly but not moved to the trash bin - all clients get information about deleted entry (they're removed from the group/folder) but not moved to trash bin ### Relevant logs  None.

kerem closed this issue

2026-03-03 02:02:58 +03:00

kerem commented

2026-03-03 02:02:59 +03:00

Author

Owner

@jjlin commented on GitHub (Aug 2, 2020):

This should be fixed in PR #1076. You can use the testing tag or wait for the next release.

@jjlin commented on GitHub (Aug 2, 2020): This should be fixed in PR #1076. You can use the `testing` tag or wait for the next release.

kerem commented

2026-03-03 02:02:59 +03:00

Author

Owner

@Sazzels commented on GitHub (Aug 2, 2020):

This should be fixed in PR #1076. You can use the testing tag or wait for the next release.

I should've also looked in commit section or closed issues.
Thank you very much for the fix and your reply.

@Sazzels commented on GitHub (Aug 2, 2020): > > > This should be fixed in PR #1076. You can use the `testing` tag or wait for the next release. I should've also looked in commit section or closed issues. Thank you very much for the fix and your reply.