[GH-ISSUE #7188] ALLOW_SEND env var / allowing send in admin panel - not working #39884

New Issue

Closed

opened 2026-07-17 20:14:58 -05:00 by GiteaMirror · 0 comments

GiteaMirror commented 2026-07-17 20:14:58 -05:00

Owner

Copy Link

Originally created by @maxhoheiser on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7188

Prerequisites

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

Vaultwarden Support String

Subject: "Enterprise Policy" error when creating Sends (400 Bad Request) despite SENDS_ALLOWED=true

Describe the bug
I am unable to create new Bitwarden Sends. Even though SENDS_ALLOWED is set to true and the Admin Panel reflects this, the container logs an error claiming an Enterprise Policy is preventing the action.

Environment

• Vaultwarden version: 1.35.7-alpine
• Install method: Docker (via Dokploy/Traefik)
• Relevant features: SSO enabled (Azure AD), SENDS_ALLOWED=true, DOMAIN=https://mydomain.sub.at

Actual behavior (Logs)
The container logs show:

[2026-05-05 12:55:05.742][request][INFO] POST /api/sends
[2026-05-05 12:55:05.744][vaultwarden::api::core::sends][ERROR] Due to an Enterprise Policy, you are only able to delete an existing Send.
[2026-05-05 12:55:05.744][response][INFO] (post_send) POST /api/sends => 400 Bad Request

Docker Compose Configuration

services:
  vaultwarden:
    image: vaultwarden/server:1.35.7-alpine
    restart: on-failure
    environment:
      - ADMIN_TOKEN=${ADMIN_TOKEN}
      - WEBSOCKET_ENABLED=true
      - DOMAIN=${DOMAIN}
      - SENDS_ALLOWED=${SENDS_ALLOWED}
      - ENABLESMTP=${ENABLESMTP}
      - SIGNUPS_ALLOWED=${SIGNUPS_ALLOWED}
      - INVITATIONS_ALLOWED=${INVITATIONS_ALLOWED}
      - ORG_GROUPS_ENABLED=${ORG_GROUPS_ENABLED}
      - ORG_CREATION_USERS=${ORG_CREATION_USERS}
      - INVITATION_ORG_NAME=${INVITATION_ORG_NAME}
      - SIGNUPS_DOMAINS_WHITELIST=${SIGNUPS_DOMAINS_WHITELIST}
      - INVITATION_EXPIRATION_HOURS=${INVITATION_EXPIRATION_HOURS}
      - EMAIL_CHANGE_ALLOWED=${EMAIL_CHANGE_ALLOWED}
      - INCOMPLETE_2FA_TIME_LIMIT=${INCOMPLETE_2FA_TIME_LIMIT}
      - SSO_ENABLED=${SSO_ENABLED}
      - SSO_ONLY=${SSO_ONLY}
      - SSO_AUTHORITY=https://login.microsoftonline.com/${DIRECTORY_ID}/v2.0
      - SSO_SCOPES=openid profile offline_access User.Read
      - SSO_CLIENT_ID=${SSO_CLIENT_ID}
      - SSO_CLIENT_SECRET=${SSO_CLIENT_SECRET}
      - USE_SYSLOG=${USE_SYSLOG}
      - LOG_LEVEL=${LOG_LEVEL}
    volumes:
      - vaultwarden-data:/data/
    expose:
      - 80
    networks:
      - vaultwarden-vaultwarden-yhdewa
    labels:
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.rule=Host(`save.res.at`)
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.entrypoints=web
      - traefik.http.services.vaultwarden-vaultwarden-yhdewa-6-web.loadbalancer.server.port=80
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.service=vaultwarden-vaultwarden-yhdewa-6-web
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.middlewares=redirect-to-https@file
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.rule=Host(`save.res.at`)
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.entrypoints=websecure
      - traefik.http.services.vaultwarden-vaultwarden-yhdewa-6-websecure.loadbalancer.server.port=80
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.service=vaultwarden-vaultwarden-yhdewa-6-websecure
      - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.tls.certresolver=letsencrypt
      - traefik.enable=true
  backup-scaleway:
    image: ttionya/vaultwarden-backup:1.26.3
    restart: on-failure
    environment:
      - RCLONE_REMOTE_NAME=${RCLONE_REMOTE_NAME_SCALEWAY}
      - RCLONE_REMOTE_DIR=${RCLONE_REMOTE_DIR_SCALEWAY}
      - RCLONE_GLOBAL_FLAG=${RCLONE_GLOBAL_FLAG_SCALEWAY}
      - CRON=${CRON}
      - ZIP_ENABLE=${ZIP_ENABLE}
      - ZIP_PASSWORD=${ZIP_PASSWORD}
      - ZIP_TYPE=${ZIP_TYPE}
      - BACKUP_FILE_SUFFIX=${BACKUP_FILE_SUFFIX}
      - BACKUP_KEEP_DAYS=${BACKUP_KEEP_DAYS}
      - TIMEZONE=${TIMEZONE}
    volumes:
      - vaultwarden-data:/bitwarden/data/
      - vaultwarden-rclone-scaleway-data:/config/
    networks:
      - vaultwarden-vaultwarden-yhdewa
  backup-aws:
    image: ttionya/vaultwarden-backup:1.26.3
    restart: on-failure
    environment:
      - RCLONE_REMOTE_NAME=${RCLONE_REMOTE_NAME_AWS}
      - RCLONE_REMOTE_DIR=${RCLONE_REMOTE_DIR_AWS}
      - RCLONE_GLOBAL_FLAG=${RCLONE_GLOBAL_FLAG_AWS}
      - CRON=${CRON}
      - ZIP_ENABLE=${ZIP_ENABLE}
      - ZIP_PASSWORD=${ZIP_PASSWORD}
      - ZIP_TYPE=${ZIP_TYPE}
      - BACKUP_FILE_SUFFIX=${BACKUP_FILE_SUFFIX}
      - BACKUP_KEEP_DAYS=${BACKUP_KEEP_DAYS}
      - TIMEZONE=${TIMEZONE}
    volumes:
      - vaultwarden-data:/bitwarden/data/
      - vaultwarden-rclone-aws-data:/config/
    networks:
      - vaultwarden-vaultwarden-yhdewa
volumes:
  vaultwarden-data:
    external: true
    name: vaultwarden-data
  vaultwarden-rclone-scaleway-data:
    external: true
    name: vaultwarden-rclone-scaleway-data
  vaultwarden-rclone-aws-data:
    external: true
    name: vaultwarden-rclone-aws-data
networks:
  vaultwarden-vaultwarden-yhdewa:
    name: vaultwarden-vaultwarden-yhdewa
    external: true

Additional Context
I am the admin and there are no specific enterprise policies configured within the organization settings that should restrict Sends. This started occurring on version 1.35.7.

Vaultwarden Build Version

1.35.7-alpine

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

traefik

Host/Server Operating System

Linux

Operating System Version

debian 13

Clients

Desktop

Client Version

No response

Steps To Reproduce

1. Log in to the web vault (SSO-enabled account).
2. Or use Mac or Windows Bitwarden Desktop App
3. Attempt to create a new "Send" (Text or File).
4. The UI fails, and the logs show a 400 error.

Expected Result

New Sends should be created successfully since they are enabled in the environment configuration.

Actual Result

4. The UI fails, and the logs show a 400 error.
5. Desktop App: Due to enterprise policy you can only delete send

Logs

Screenshots or Videos

No response

Additional Context

No response

Originally created by @maxhoheiser on GitHub (May 5, 2026). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7188 ### 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 ### Subject: "Enterprise Policy" error when creating Sends (400 Bad Request) despite SENDS_ALLOWED=true **Describe the bug** I am unable to create new Bitwarden Sends. Even though `SENDS_ALLOWED` is set to `true` and the Admin Panel reflects this, the container logs an error claiming an Enterprise Policy is preventing the action. **Environment** * **Vaultwarden version:** 1.35.7-alpine * **Install method:** Docker (via Dokploy/Traefik) * **Relevant features:** SSO enabled (Azure AD), SENDS_ALLOWED=true, DOMAIN=<https://mydomain.sub.at> **Actual behavior (Logs)** The container logs show: ```text [2026-05-05 12:55:05.742][request][INFO] POST /api/sends [2026-05-05 12:55:05.744][vaultwarden::api::core::sends][ERROR] Due to an Enterprise Policy, you are only able to delete an existing Send. [2026-05-05 12:55:05.744][response][INFO] (post_send) POST /api/sends => 400 Bad Request ``` **Docker Compose Configuration** ```yaml services: vaultwarden: image: vaultwarden/server:1.35.7-alpine restart: on-failure environment: - ADMIN_TOKEN=${ADMIN_TOKEN} - WEBSOCKET_ENABLED=true - DOMAIN=${DOMAIN} - SENDS_ALLOWED=${SENDS_ALLOWED} - ENABLESMTP=${ENABLESMTP} - SIGNUPS_ALLOWED=${SIGNUPS_ALLOWED} - INVITATIONS_ALLOWED=${INVITATIONS_ALLOWED} - ORG_GROUPS_ENABLED=${ORG_GROUPS_ENABLED} - ORG_CREATION_USERS=${ORG_CREATION_USERS} - INVITATION_ORG_NAME=${INVITATION_ORG_NAME} - SIGNUPS_DOMAINS_WHITELIST=${SIGNUPS_DOMAINS_WHITELIST} - INVITATION_EXPIRATION_HOURS=${INVITATION_EXPIRATION_HOURS} - EMAIL_CHANGE_ALLOWED=${EMAIL_CHANGE_ALLOWED} - INCOMPLETE_2FA_TIME_LIMIT=${INCOMPLETE_2FA_TIME_LIMIT} - SSO_ENABLED=${SSO_ENABLED} - SSO_ONLY=${SSO_ONLY} - SSO_AUTHORITY=https://login.microsoftonline.com/${DIRECTORY_ID}/v2.0 - SSO_SCOPES=openid profile offline_access User.Read - SSO_CLIENT_ID=${SSO_CLIENT_ID} - SSO_CLIENT_SECRET=${SSO_CLIENT_SECRET} - USE_SYSLOG=${USE_SYSLOG} - LOG_LEVEL=${LOG_LEVEL} volumes: - vaultwarden-data:/data/ expose: - 80 networks: - vaultwarden-vaultwarden-yhdewa labels: - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.rule=Host(`save.res.at`) - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.entrypoints=web - traefik.http.services.vaultwarden-vaultwarden-yhdewa-6-web.loadbalancer.server.port=80 - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.service=vaultwarden-vaultwarden-yhdewa-6-web - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-web.middlewares=redirect-to-https@file - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.rule=Host(`save.res.at`) - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.entrypoints=websecure - traefik.http.services.vaultwarden-vaultwarden-yhdewa-6-websecure.loadbalancer.server.port=80 - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.service=vaultwarden-vaultwarden-yhdewa-6-websecure - traefik.http.routers.vaultwarden-vaultwarden-yhdewa-6-websecure.tls.certresolver=letsencrypt - traefik.enable=true backup-scaleway: image: ttionya/vaultwarden-backup:1.26.3 restart: on-failure environment: - RCLONE_REMOTE_NAME=${RCLONE_REMOTE_NAME_SCALEWAY} - RCLONE_REMOTE_DIR=${RCLONE_REMOTE_DIR_SCALEWAY} - RCLONE_GLOBAL_FLAG=${RCLONE_GLOBAL_FLAG_SCALEWAY} - CRON=${CRON} - ZIP_ENABLE=${ZIP_ENABLE} - ZIP_PASSWORD=${ZIP_PASSWORD} - ZIP_TYPE=${ZIP_TYPE} - BACKUP_FILE_SUFFIX=${BACKUP_FILE_SUFFIX} - BACKUP_KEEP_DAYS=${BACKUP_KEEP_DAYS} - TIMEZONE=${TIMEZONE} volumes: - vaultwarden-data:/bitwarden/data/ - vaultwarden-rclone-scaleway-data:/config/ networks: - vaultwarden-vaultwarden-yhdewa backup-aws: image: ttionya/vaultwarden-backup:1.26.3 restart: on-failure environment: - RCLONE_REMOTE_NAME=${RCLONE_REMOTE_NAME_AWS} - RCLONE_REMOTE_DIR=${RCLONE_REMOTE_DIR_AWS} - RCLONE_GLOBAL_FLAG=${RCLONE_GLOBAL_FLAG_AWS} - CRON=${CRON} - ZIP_ENABLE=${ZIP_ENABLE} - ZIP_PASSWORD=${ZIP_PASSWORD} - ZIP_TYPE=${ZIP_TYPE} - BACKUP_FILE_SUFFIX=${BACKUP_FILE_SUFFIX} - BACKUP_KEEP_DAYS=${BACKUP_KEEP_DAYS} - TIMEZONE=${TIMEZONE} volumes: - vaultwarden-data:/bitwarden/data/ - vaultwarden-rclone-aws-data:/config/ networks: - vaultwarden-vaultwarden-yhdewa volumes: vaultwarden-data: external: true name: vaultwarden-data vaultwarden-rclone-scaleway-data: external: true name: vaultwarden-rclone-scaleway-data vaultwarden-rclone-aws-data: external: true name: vaultwarden-rclone-aws-data networks: vaultwarden-vaultwarden-yhdewa: name: vaultwarden-vaultwarden-yhdewa external: true ``` **Additional Context** I am the admin and there are no specific enterprise policies configured within the organization settings that should restrict Sends. This started occurring on version 1.35.7. ### Vaultwarden Build Version 1.35.7-alpine ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy traefik ### Host/Server Operating System Linux ### Operating System Version debian 13 ### Clients Desktop ### Client Version _No response_ ### Steps To Reproduce 1. Log in to the web vault (SSO-enabled account). 2. Or use Mac or Windows Bitwarden Desktop App 3. Attempt to create a new "Send" (Text or File). 4. The UI fails, and the logs show a 400 error. ### Expected Result New Sends should be created successfully since they are enabled in the environment configuration. ### Actual Result 4. The UI fails, and the logs show a 400 error. 5. Desktop App: Due to enterprise policy you can only delete send ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_

GiteaMirror added the bug label 2026-07-17 20:14:58 -05:00

GiteaMirror closed this issue 2026-07-17 20:15:09 -05:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

revert-7033-patch-1

cached-config-operations

test_dylint

1.36.0

1.35.8

1.35.7

1.35.6

1.35.5

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels

better for forum

bug

documentation

duplicate

enhancement

future Vault

good first issue

help wanted

low priority

notes

pull-request

Mirrored from GitHub Pull Request

question

SSO

Third party

troubleshooting

wontfix

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#39884