starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Database connection fails because of failed name resolution #1455

New Issue
Closed
opened 2026-02-05 00:59:23 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2026-02-05 00:59:23 +03:00
Owner
Copy Link

Originally created by @MasinAD on GitHub (Dec 28, 2022).

Subject of the issue

I configured the MariaDB connection in the environment file.

DATABASE_URL=mysql://vaultwarden:<password>@db:3306/vaultwarden

On startup I get

Dec 28 01:04:22 vaultwarden vaultwarden[1132]: [2022-12-28 01:04:22.611][vaultwarden::util][WARN] Can't connect to database, retrying: DieselCon.
Dec 28 01:04:22 vaultwarden vaultwarden[1132]: [CAUSE] BadConnection(
Dec 28 01:04:22 vaultwarden vaultwarden[1132]:     "Unknown server host 'db' (-3)",
Dec 28 01:04:22 vaultwarden vaultwarden[1132]: )

Deployment environment

  • vaultwarden version: 1.27
  • Install method: binary extracted from Docker image
  • MySQL/MariaDB or PostgreSQL version: mariadb Ver 15.1 Distrib 10.5.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
  • Other relevant details: My setup consists of systemd-nspawn containers connected in a private virtual network zone
[Network]
VirtualEthernet=yes
Private=yes
Zone=persephone

The db nspawn container has a similar config. This setup works.

root@vaultwarden:~# getent ahosts db
169.254.102.26  STREAM db
169.254.102.26  DGRAM  
169.254.102.26  RAW    
192.168.104.15  STREAM 
192.168.104.15  DGRAM  
192.168.104.15  RAW    
fe80::f836:5aff:fe6c:d3fd STREAM 
fe80::f836:5aff:fe6c:d3fd DGRAM  
fe80::f836:5aff:fe6c:d3fd RAW    
root@vaultwarden:~# host db
db has address 169.254.102.26
db has address 192.168.104.15
db has IPv6 address fe80::f836:5aff:fe6c:d3fd

Steps to reproduce

Setup two systemd-nspawn containers by bootstrapping Debian Bullseye. Name one db and the other vaultwarden. Install MariaDB in the first and the vaultwarden binary in the second (together with the web-vault).

Create a systemd service unit file:

# /etc/systemd/system/vaultwarden.service
[Unit]
Description=Vaultwarden
Documentation=https://github.com/dani-garcia/vaultwarden
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/default/vaultwarden
ExecStart=/usr/local/bin/vaultwarden

# Set reasonable connection and process limits
LimitNOFILE=1048576
LimitNPROC=64
# Isolate vaultwarden from the rest of the system
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict

Restart=always
RestartSec=10
WorkingDirectory=/srv/vaultwarden/
ReadWriteDirectories=/srv/vaultwarden/ 
User=vaultwarden
Group=vaultwarden

[Install]
WantedBy=multi-user.target

Create a system user and a system group, both named vaultwarden

Expected behaviour

Vaultwarden connects to the database by simply resolving the database name using system standards

Actual behaviour

Vaultwarden fails to connect because Diesel seems to not resolve the name correctly.

Troubleshooting data

Originally created by @MasinAD on GitHub (Dec 28, 2022). <!-- # ### 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 I configured the MariaDB connection in the environment file. ``` DATABASE_URL=mysql://vaultwarden:<password>@db:3306/vaultwarden ``` On startup I get ``` Dec 28 01:04:22 vaultwarden vaultwarden[1132]: [2022-12-28 01:04:22.611][vaultwarden::util][WARN] Can't connect to database, retrying: DieselCon. Dec 28 01:04:22 vaultwarden vaultwarden[1132]: [CAUSE] BadConnection( Dec 28 01:04:22 vaultwarden vaultwarden[1132]: "Unknown server host 'db' (-3)", Dec 28 01:04:22 vaultwarden vaultwarden[1132]: ) ``` <!-- Describe your issue here. --> ### 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 <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: binary extracted from Docker image * MySQL/MariaDB or PostgreSQL version: mariadb Ver 15.1 Distrib 10.5.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper * Other relevant details: My setup consists of systemd-nspawn containers connected in a private virtual network zone ``` [Network] VirtualEthernet=yes Private=yes Zone=persephone ``` The db nspawn container has a similar config. This setup **works**. ``` root@vaultwarden:~# getent ahosts db 169.254.102.26 STREAM db 169.254.102.26 DGRAM 169.254.102.26 RAW 192.168.104.15 STREAM 192.168.104.15 DGRAM 192.168.104.15 RAW fe80::f836:5aff:fe6c:d3fd STREAM fe80::f836:5aff:fe6c:d3fd DGRAM fe80::f836:5aff:fe6c:d3fd RAW root@vaultwarden:~# host db db has address 169.254.102.26 db has address 192.168.104.15 db has IPv6 address fe80::f836:5aff:fe6c:d3fd ``` ### 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? --> Setup two systemd-nspawn containers by bootstrapping Debian Bullseye. Name one `db` and the other `vaultwarden`. Install MariaDB in the first and the vaultwarden binary in the second (together with the web-vault). Create a systemd service unit file: ``` # /etc/systemd/system/vaultwarden.service [Unit] Description=Vaultwarden Documentation=https://github.com/dani-garcia/vaultwarden After=network.target [Service] Type=simple EnvironmentFile=/etc/default/vaultwarden ExecStart=/usr/local/bin/vaultwarden # Set reasonable connection and process limits LimitNOFILE=1048576 LimitNPROC=64 # Isolate vaultwarden from the rest of the system PrivateTmp=true PrivateDevices=true ProtectHome=true ProtectSystem=strict Restart=always RestartSec=10 WorkingDirectory=/srv/vaultwarden/ ReadWriteDirectories=/srv/vaultwarden/ User=vaultwarden Group=vaultwarden [Install] WantedBy=multi-user.target ``` Create a system user and a system group, both named `vaultwarden` ### Expected behaviour <!-- Tell us what you expected to happen --> Vaultwarden connects to the database by simply resolving the database name using system standards ### Actual behaviour <!-- Tell us what actually happened --> Vaultwarden fails to connect because Diesel seems to not resolve the name correctly. ### Troubleshooting data <!-- Share any log files, screenshots, or other relevant troubleshooting data -->
OVERLORD added the troubleshootingThird party labels 2026-02-05 00:59:23 +03:00
OVERLORD commented 2026-02-05 00:59:27 +03:00
Author
Owner
Copy Link

@MasinAD commented on GitHub (Dec 28, 2022):

For the record, my workaround is providing the db host's IP address. But I'd like to resolve names in case of rebooting everything and the host then getting a different IP address. DHCP and DNS are cool if they work and are properly applied ;-).

@MasinAD commented on GitHub (Dec 28, 2022): For the record, my workaround is providing the db host's IP address. But I'd like to resolve names in case of rebooting everything and the host then getting a different IP address. DHCP and DNS are cool if they work and are properly applied ;-).
OVERLORD commented 2026-02-05 00:59:31 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Dec 28, 2022):

Not sure that we can help here. Resolving normally goes via the resolving provided by system it self. If this is a diesel issue, then a issue report there would be better.

What happens if you use getent to try and resolve the host within your nspawn container? Or any other resolving tool?

@BlackDex commented on GitHub (Dec 28, 2022): Not sure that we can help here. Resolving normally goes via the resolving provided by system it self. If this is a diesel issue, then a issue report there would be better. What happens if you use `getent` to try and resolve the host within your nspawn container? Or any other resolving tool?
OVERLORD commented 2026-02-05 00:59:35 +03:00
Author
Owner
Copy Link

@MasinAD commented on GitHub (Dec 28, 2022):

I agree I should report this to Diesel. Done here: https://github.com/diesel-rs/diesel/issues/3463

I already posted the output of getent ahosts db and host db but I paste it here:

root@vaultwarden:~# getent ahosts db
169.254.102.26  STREAM db
169.254.102.26  DGRAM  
169.254.102.26  RAW    
192.168.104.15  STREAM 
192.168.104.15  DGRAM  
192.168.104.15  RAW    
fe80::f836:5aff:fe6c:d3fd STREAM 
fe80::f836:5aff:fe6c:d3fd DGRAM  
fe80::f836:5aff:fe6c:d3fd RAW    
root@vaultwarden:~# host db
db has address 169.254.102.26
db has address 192.168.104.15
db has IPv6 address fe80::f836:5aff:fe6c:d3fd

Resolving actually works. But Diesel does not like it.

@MasinAD commented on GitHub (Dec 28, 2022): I agree I should report this to Diesel. Done here: https://github.com/diesel-rs/diesel/issues/3463 I already posted the output of `getent ahosts db` and `host db` but I paste it here: ``` root@vaultwarden:~# getent ahosts db 169.254.102.26 STREAM db 169.254.102.26 DGRAM 169.254.102.26 RAW 192.168.104.15 STREAM 192.168.104.15 DGRAM 192.168.104.15 RAW fe80::f836:5aff:fe6c:d3fd STREAM fe80::f836:5aff:fe6c:d3fd DGRAM fe80::f836:5aff:fe6c:d3fd RAW root@vaultwarden:~# host db db has address 169.254.102.26 db has address 192.168.104.15 db has IPv6 address fe80::f836:5aff:fe6c:d3fd ``` Resolving actually works. But Diesel does not like it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label Third party troubleshooting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1455
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?