starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 01:35:54 +03:00
Code Issues 39 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #392] SMTP Error #226

New issue
Closed
opened 2026-03-03 01:26:56 +03:00 by kerem · 4 comments
kerem commented 2026-03-03 01:26:56 +03:00
Owner
Copy link

Originally created by @niklasdahlheimer on GitHub (Feb 10, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/392

Hey Guys,

I installed the docker image on our Synology-Docker. First of all: Thank you for the really easy way of configuring the container!

I have to issues:

  1. If I do not regulate the CPU-usage, the bitwarden-container drives up to nearly 50% of CPU-usage over the time. With lowering the priority it still pumps up to 12%. is this correct? All our other containers (mysql, nginx, wekan,...) use around 0.5-2% CPU...the bitwarden container starts with 0% and then grows over the time, looks like kind of a memory leak...

  2. SMTP is not working. The credentials are working in the other containers, so I guess it's not a problem with our mail-server (i also tried a googlemail-server to prove that). When I try to send an invitation mail
    via SSL (Port 465), the log says:
    [2019-02-10 16:41:24][lettre::smtp::client][DEBUG] connecting to ...:465
    (** is our public IP)

our synology:
RS3614xs+, INTEL Xeon E3-1230 v2, DSM 6.2.1-23824 Update 4

A json dump of the container config with hidden (**) credentials

   "cap_add" : null,
   "cap_drop" : null,
   "cmd" : "/bin/sh -c ./bitwarden_rs",
   "cpu_priority" : 10,
   "devices" : null,
   "enable_publish_all_ports" : false,
   "enable_restart_policy" : false,
   "enabled" : true,
   "env_variables" : [
      {
         "key" : "LOG_FILE",
         "value" : "/data/bitwarden.log"
      },
      {
         "key" : "ADMIN_TOKEN",
         "value" : "***************************************************************"
      },
      {
         "key" : "SIGNUPS_ALLOWED",
         "value" : "false"
      },
      {
         "key" : "DOMAIN",
         "value" : "*.**********.de"
      },
      {
         "key" : "SMTP_PASSWORD",
         "value" : "****************"
      },
      {
         "key" : "SMTP_USERNAME",
         "value" : "admin"
      },
      {
         "key" : "SMTP_SSL",
         "value" : "true"
      },
      {
         "key" : "SMTP_PORT",
         "value" : "465"
      },
      {
         "key" : "SMTP_FROM",
         "value" : "admin@****************.de"
      },
      {
         "key" : "SMTP_HOST",
         "value" : "mail.*************.de"
      },
      {
         "key" : "PATH",
         "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      },
      {
         "key" : "ROCKET_ENV",
         "value" : "staging"
      },
      {
         "key" : "ROCKET_PORT",
         "value" : "80"
      },
      {
         "key" : "ROCKET_WORKERS",
         "value" : "10"
      }
   ],
   "exporting" : false,
   "id" : "2fddab0a4c9d0039de78406153bf6b6a5ae01f4094c5041c63e1161b2dcd797f",
   "image" : "mprasil/bitwarden:latest",
   "is_ddsm" : false,
   "is_package" : false,
   "links" : [],
   "memory_limit" : 2171600896,
   "name" : "bitwarden",
   "network" : [
      {
         "driver" : "bridge",
         "name" : "bridge"
      }
   ],
   "network_mode" : "bridge",
   "port_bindings" : [
      {
         "container_port" : 3012,
         "host_port" : 0,
         "type" : "tcp"
      },
      {
         "container_port" : 80,
         "host_port" : 8070,
         "type" : "tcp"
      }
   ],
   "privileged" : false,
   "shortcut" : {
      "enable_shortcut" : false
   },
   "ulimits" : null,
   "use_host_network" : false,
   "volume_bindings" : [
      {
         "host_volume_file" : "/docker/Bitwarden",
         "mount_point" : "/data/",
         "type" : "rw"
      }
   ],
   "volumes_from" : null
}

Looking forward for your responses! Thank you!

Originally created by @niklasdahlheimer on GitHub (Feb 10, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/392 Hey Guys, I installed the docker image on our Synology-Docker. First of all: Thank you for the really easy way of configuring the container! I have to issues: 1. If I do not regulate the CPU-usage, the bitwarden-container drives up to nearly 50% of CPU-usage over the time. With lowering the priority it still pumps up to 12%. is this correct? All our other containers (mysql, nginx, wekan,...) use around 0.5-2% CPU...the bitwarden container starts with 0% and then grows over the time, looks like kind of a memory leak... 2. SMTP is not working. The credentials are working in the other containers, so I guess it's not a problem with our mail-server (i also tried a googlemail-server to prove that). When I try to send an invitation mail via SSL (Port 465), the log says: [2019-02-10 16:41:24][lettre::smtp::client][DEBUG] connecting to **.**.**.**:465 (** is our public IP) our synology: RS3614xs+, INTEL Xeon E3-1230 v2, DSM 6.2.1-23824 Update 4 A json dump of the container config with hidden (**) credentials ```{ "cap_add" : null, "cap_drop" : null, "cmd" : "/bin/sh -c ./bitwarden_rs", "cpu_priority" : 10, "devices" : null, "enable_publish_all_ports" : false, "enable_restart_policy" : false, "enabled" : true, "env_variables" : [ { "key" : "LOG_FILE", "value" : "/data/bitwarden.log" }, { "key" : "ADMIN_TOKEN", "value" : "***************************************************************" }, { "key" : "SIGNUPS_ALLOWED", "value" : "false" }, { "key" : "DOMAIN", "value" : "*.**********.de" }, { "key" : "SMTP_PASSWORD", "value" : "****************" }, { "key" : "SMTP_USERNAME", "value" : "admin" }, { "key" : "SMTP_SSL", "value" : "true" }, { "key" : "SMTP_PORT", "value" : "465" }, { "key" : "SMTP_FROM", "value" : "admin@****************.de" }, { "key" : "SMTP_HOST", "value" : "mail.*************.de" }, { "key" : "PATH", "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }, { "key" : "ROCKET_ENV", "value" : "staging" }, { "key" : "ROCKET_PORT", "value" : "80" }, { "key" : "ROCKET_WORKERS", "value" : "10" } ], "exporting" : false, "id" : "2fddab0a4c9d0039de78406153bf6b6a5ae01f4094c5041c63e1161b2dcd797f", "image" : "mprasil/bitwarden:latest", "is_ddsm" : false, "is_package" : false, "links" : [], "memory_limit" : 2171600896, "name" : "bitwarden", "network" : [ { "driver" : "bridge", "name" : "bridge" } ], "network_mode" : "bridge", "port_bindings" : [ { "container_port" : 3012, "host_port" : 0, "type" : "tcp" }, { "container_port" : 80, "host_port" : 8070, "type" : "tcp" } ], "privileged" : false, "shortcut" : { "enable_shortcut" : false }, "ulimits" : null, "use_host_network" : false, "volume_bindings" : [ { "host_volume_file" : "/docker/Bitwarden", "mount_point" : "/data/", "type" : "rw" } ], "volumes_from" : null } ``` Looking forward for your responses! Thank you!
kerem closed this issue 2026-03-03 01:26:56 +03:00
kerem commented 2026-03-03 01:26:57 +03:00
Author
Owner
Copy link

@dani-garcia commented on GitHub (Feb 10, 2019):

The server should basically use no resources when it's idle and not processing any requests. We've had some users in the past have some extra CPU usage when the websockets server is enabled, but I couldn't replicate it (and you don't seem to have it enabled anyway). How long does the process need to be running to reach the CPU usage you mention?

The SMTP issue seems weird. It looks like it can't reach the server. Can you make sure that the docker container has access to the mail server network somehow? If the mail server is in a public IP, you could just check that the container has internet access by making sure that the website icons download correctly.

<!-- gh-comment-id:462163870 --> @dani-garcia commented on GitHub (Feb 10, 2019): The server should basically use no resources when it's idle and not processing any requests. We've had some users in the past have some extra CPU usage when the websockets server is enabled, but I couldn't replicate it (and you don't seem to have it enabled anyway). How long does the process need to be running to reach the CPU usage you mention? The SMTP issue seems weird. It looks like it can't reach the server. Can you make sure that the docker container has access to the mail server network somehow? If the mail server is in a public IP, you could just check that the container has internet access by making sure that the website icons download correctly.
kerem commented 2026-03-03 01:26:57 +03:00
Author
Owner
Copy link

@niklasdahlheimer commented on GitHub (Feb 11, 2019):

Hey!
Thanks for the quick response!

  1. After the container-restart yesterday the container stayed at 0% CPU, I will observe that but can not reproduce it anymore (what is also kind of good :) )

  2. About the SMTP issue:
    When I try to connect to the mailserver without SSL via port 25 the log says:

[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] connecting to ***.***.****.***:25
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 220 mail.company.de ESMTP ready<CRLF>
[2019-02-10 16:28:08][lettre::smtp][INFO] connection established to ***.***.****.***:25
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: EHLO bitwarden<CRLF>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 250-mail.company.de<CRLF>250-AUTH<CRLF>250-STARTTLS<CRLF>250-ENHANCEDSTATUSCODES<CRLF>250-8BITMIME<CRLF>250-PIPELINING<CRLF>250-ETRN<CRLF>250-DSN<CRLF>250 HELP<CRLF>
[2019-02-10 16:28:08][lettre::smtp][DEBUG] server mail.company.de with {EightBitMime, StartTls}
[2019-02-10 16:28:08][lettre::smtp][INFO] No supported authentication mechanisms available
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: MAIL FROM:<admin@company.de> BODY=8BITMIME<CRLF>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 250 2.1.0 Sender <admin@company.de> ok<CRLF>
[2019-02-10 16:28:08][lettre::smtp][INFO] ce66e524-03ea-4b89-81a4-71b5124faf11: from=<admin@company.de>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: RCPT TO:<someone@web.de><CRLF>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 550 5.7.1 Relaying to <someone@web.de> denied (authentication required)<CRLF>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF>
[2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 221 2.0.0 SMTP closing connection<CRLF>

So i guess the access to the network access to the mailserver could not be the problem.

when i google about SMTP and bitwarden I found out about a variable
globalSettings__mail__smtp__useDefaultCredentials
Could that be some source of problem?

Should I provide more logs?

Greetings

<!-- gh-comment-id:462486141 --> @niklasdahlheimer commented on GitHub (Feb 11, 2019): Hey! Thanks for the quick response! 1. After the container-restart yesterday the container stayed at 0% CPU, I will observe that but can not reproduce it anymore (what is also kind of good :) ) 2. About the SMTP issue: When I try to connect to the mailserver without SSL via port 25 the log says: ``` [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] connecting to ***.***.****.***:25 [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 220 mail.company.de ESMTP ready<CRLF> [2019-02-10 16:28:08][lettre::smtp][INFO] connection established to ***.***.****.***:25 [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: EHLO bitwarden<CRLF> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 250-mail.company.de<CRLF>250-AUTH<CRLF>250-STARTTLS<CRLF>250-ENHANCEDSTATUSCODES<CRLF>250-8BITMIME<CRLF>250-PIPELINING<CRLF>250-ETRN<CRLF>250-DSN<CRLF>250 HELP<CRLF> [2019-02-10 16:28:08][lettre::smtp][DEBUG] server mail.company.de with {EightBitMime, StartTls} [2019-02-10 16:28:08][lettre::smtp][INFO] No supported authentication mechanisms available [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: MAIL FROM:<admin@company.de> BODY=8BITMIME<CRLF> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 250 2.1.0 Sender <admin@company.de> ok<CRLF> [2019-02-10 16:28:08][lettre::smtp][INFO] ce66e524-03ea-4b89-81a4-71b5124faf11: from=<admin@company.de> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: RCPT TO:<someone@web.de><CRLF> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 550 5.7.1 Relaying to <someone@web.de> denied (authentication required)<CRLF> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF> [2019-02-10 16:28:08][lettre::smtp::client][DEBUG] Read: 221 2.0.0 SMTP closing connection<CRLF> ``` So i guess the access to the network access to the mailserver could not be the problem. when i google about SMTP and bitwarden I found out about a variable `globalSettings__mail__smtp__useDefaultCredentials` Could that be some source of problem? Should I provide more logs? Greetings
kerem commented 2026-03-03 01:26:57 +03:00
Author
Owner
Copy link

@dani-garcia commented on GitHub (Feb 11, 2019):

I think the problem might be related to the connection type we are using to securely connect to the server.

At the moment we are starting with an insecure connection that is then upgraded with STARTTLS, but there is also an option to just wrap the entire connection in a normal TLS layer.

I know of some SMTP servers which use different ports for those two options (like fastmail, which uses 25 or 587 with STARTTLS or 465 with a TLS wrapper), which may be your case.

The upstream settings are not used here so that shouldn't affect anything. I would make sure that all the options appear correctly in the SMTP section of the admin panel, and try using either port 25 or 587 with SSL enabled hoping that the server would accept a STARTLS upgrade in those ports.

If that doesn't work, I could create an option to select between those connection modes.

Also, why does your unencrypted example fail with authentication required? Check in the admin panel if the SMTP username and password are set correctly.

<!-- gh-comment-id:462496142 --> @dani-garcia commented on GitHub (Feb 11, 2019): I think the problem might be related to the connection type we are using to securely connect to the server. At the moment we are starting with an insecure connection that is then upgraded with STARTTLS, but there is also an option to just wrap the entire connection in a normal TLS layer. I know of some SMTP servers which use different ports for those two options (like fastmail, which uses `25` or `587` with STARTTLS or `465` with a TLS wrapper), which may be your case. The upstream settings are not used here so that shouldn't affect anything. I would make sure that all the options appear correctly in the SMTP section of the admin panel, and try using either port `25` or `587` with SSL enabled hoping that the server would accept a STARTLS upgrade in those ports. If that doesn't work, I could create an option to select between those connection modes. Also, why does your unencrypted example fail with authentication required? Check in the admin panel if the SMTP username and password are set correctly.
kerem commented 2026-03-03 01:26:57 +03:00
Author
Owner
Copy link

@niklasdahlheimer commented on GitHub (Feb 11, 2019):

Hey!
Connecting to Port 25 with SSL did the job! Great idea!

We are using a Kerio Connect Mail server.

I don't know either why the nonSSL Login via Port 25 failed. The credentials where correct. Maybe bitwarden uses some different kind of AUTH LOGIN or something like that?

Anyway, it works now and I am happy, but if you need any more information about this issue, just tell me, I would love to contribute to this great project (without having any web-development skills :) )

<!-- gh-comment-id:462540378 --> @niklasdahlheimer commented on GitHub (Feb 11, 2019): Hey! Connecting to Port 25 with SSL did the job! Great idea! We are using a Kerio Connect Mail server. I don't know either why the nonSSL Login via Port 25 failed. The credentials where correct. Maybe bitwarden uses some different kind of AUTH LOGIN or something like that? Anyway, it works now and I am happy, but if you need any more information about this issue, just tell me, I would love to contribute to this great project (without having any web-development skills :) )
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
revert-7033-patch-1
cached-config-operations
test_dylint
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   
SSO

   
Third party

   
better for forum

   
bug

   
bug

   
documentation

   
duplicate

   
enhancement

   
future Vault

   
future Vault

   
future Vault

   
good first issue

   
help wanted

   
low priority

   
notes

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
troubleshooting

   
wontfix
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#226
No description provided.