Docker: Internal server error when accessing /admin #225

New Issue

2025-11-07T06:29:04-06:00

GiteaMirror commented

2025-11-07 06:29:04 -06:00

Originally created by @Flameborn on GitHub (Feb 9, 2019).

Hello,

I am getting a HTTP 500 server error when accessing https://bw.domain.tld/admin, or the custom port on http://localhost:4000/admin via the latest docker image.

The ADMIN_TOKEN environment variable is configured.

My log:

Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][rocket::rocket][INFO] GET /admin:
Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][][INFO] Matched: GET /<p..> [10] (web_files)
Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][][ERROR] Response was a non-Responder Err: Os { code: 2, kind: NotFound, message: "No
such file or directory" }.
Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][][INFO] Outcome: Failure
Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][][WARN] Responding with 500 Internal Server Error catcher.
Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][INFO] Response succeeded.

Originally created by @Flameborn on GitHub (Feb 9, 2019). Hello, I am getting a HTTP 500 server error when accessing _https://bw.domain.tld/admin_, or the custom port on _http://localhost:4000/admin_ via the latest docker image. The ADMIN_TOKEN environment variable is configured. My log: Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][rocket::rocket][INFO] GET /admin: Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][INFO] Matched: GET /<p..> [10] (web_files) Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][ERROR] Response was a non-`Responder` `Err`: Os { code: 2, kind: NotFound, message: "No such file or directory" }. Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][INFO] Outcome: Failure Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][WARN] Responding with 500 Internal Server Error catcher. Feb 09 20:26:34 sapphire systemd-docker[9754]: [2019-02-09 20:26:34][_][INFO] Response succeeded.

GiteaMirror closed this issue

2025-11-07 06:29:04 -06:00

GiteaMirror commented

2025-11-07 06:29:04 -06:00

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

Can you check the logs when you start the server? You should get something like this:

[2019-02-10 15:03:26][rocket::rocket][INFO] �   Mounting /admin:
[2019-02-10 15:03:26][_][INFO] GET /admin [2] (admin_login)
[2019-02-10 15:03:26][_][INFO] POST /admin (post_admin_login)
[2019-02-10 15:03:26][_][INFO] GET /admin (admin_page)
[2019-02-10 15:03:26][_][INFO] POST /admin/invite (invite_user)
[2019-02-10 15:03:26][_][INFO] POST /admin/users/<uuid>/delete (delete_user)
[2019-02-10 15:03:26][_][INFO] POST /admin/users/<uuid>/deauth (deauth_user)
[2019-02-10 15:03:26][_][INFO] POST /admin/config (post_config)
[2019-02-10 15:03:26][_][INFO] POST /admin/config/delete (delete_config)

It should be just slightly before the unofficial bitwarden warning.
If you get that in the logs, and the admin panel still gives that error it probably means that the ADMIN_TOKEN couldn't be found.

@dani-garcia commented on GitHub (Feb 10, 2019): Can you check the logs when you start the server? You should get something like this: ``` [2019-02-10 15:03:26][rocket::rocket][INFO] � Mounting /admin: [2019-02-10 15:03:26][_][INFO] GET /admin [2] (admin_login) [2019-02-10 15:03:26][_][INFO] POST /admin (post_admin_login) [2019-02-10 15:03:26][_][INFO] GET /admin (admin_page) [2019-02-10 15:03:26][_][INFO] POST /admin/invite (invite_user) [2019-02-10 15:03:26][_][INFO] POST /admin/users/<uuid>/delete (delete_user) [2019-02-10 15:03:26][_][INFO] POST /admin/users/<uuid>/deauth (deauth_user) [2019-02-10 15:03:26][_][INFO] POST /admin/config (post_config) [2019-02-10 15:03:26][_][INFO] POST /admin/config/delete (delete_config) ``` It should be just slightly before the unofficial bitwarden warning. If you get that in the logs, and the admin panel still gives that error it probably means that the ADMIN_TOKEN couldn't be found.

GiteaMirror commented

2025-11-07 06:29:05 -06:00

@Flameborn commented on GitHub (Feb 10, 2019):

After mounting the /api/ endpoints, I see:

Feb 10 14:14:32 sapphire systemd-docker[2731]: [2019-02-10 14:14:32][rocket::rocket][INFO] Mounting /admin:

There are no other admin-related mounts, the next line is an entry about mounting /identity.

@Flameborn commented on GitHub (Feb 10, 2019): After mounting the /api/ endpoints, I see: Feb 10 14:14:32 sapphire systemd-docker[2731]: [2019-02-10 14:14:32][rocket::rocket][INFO] Mounting /admin: There are no other admin-related mounts, the next line is an entry about mounting /identity.

GiteaMirror commented

2025-11-07 06:29:05 -06:00

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

That means that the admin_token wasn't detected, so the admin routes weren't mounted. Can you double check that you are setting the variable correctly? The docker steps are explained here: https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-admin-page

@dani-garcia commented on GitHub (Feb 10, 2019): That means that the admin_token wasn't detected, so the admin routes weren't mounted. Can you double check that you are setting the variable correctly? The docker steps are explained here: https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-admin-page

GiteaMirror commented

2025-11-07 06:29:05 -06:00

@Flameborn commented on GitHub (Feb 10, 2019):

I have a SystemD unit, which uses systemd-docker, the environment variables are set like this:

[Service]
TimeoutStartSec=0
Environment=SIGNUPS_ALLOWED=false ADMIN_TOKEN=RANDOM_STRING ...

The admin token has uppercase and lowercase letters, plus numbers only.

@Flameborn commented on GitHub (Feb 10, 2019): I have a SystemD unit, which uses systemd-docker, the environment variables are set like this: [Service] TimeoutStartSec=0 Environment=SIGNUPS_ALLOWED=false ADMIN_TOKEN=RANDOM_STRING ... The admin token has uppercase and lowercase letters, plus numbers only.

GiteaMirror commented

2025-11-07 06:29:06 -06:00

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

Can you check that the SIGNUPS_ALLOWED actually works? Our wiki recommends setting the EnvironmentFile, but I don't know a lot about systemd to actually now if that makes a difference.

You could also try to set both variables in different lines:
[Service]
TimeoutStartSec=0
Environment=SIGNUPS_ALLOWED=false
Environment=ADMIN_TOKEN=RANDOM_STRING

I think there is a possibility that systemd is interpreting everything after the first = like the value of the first variable.

@dani-garcia commented on GitHub (Feb 10, 2019): Can you check that the SIGNUPS_ALLOWED actually works? [Our wiki recommends](https://github.com/dani-garcia/bitwarden_rs/wiki/Setup-as-a-systemd-service) setting the `EnvironmentFile`, but I don't know a lot about systemd to actually now if that makes a difference. You could also try to set both variables in different lines: [Service] TimeoutStartSec=0 Environment=SIGNUPS_ALLOWED=false Environment=ADMIN_TOKEN=RANDOM_STRING I think there is a possibility that systemd is interpreting everything after the first `=` like the value of the first variable.

GiteaMirror commented

2025-11-07 06:29:06 -06:00

@Flameborn commented on GitHub (Feb 10, 2019):

According to this, the Environment directive allows a list of variable assignments, separated by spaces.

I've modified my unit file to have separate Environment directives, unfortunately, still no go.

systemctl show bitwarden prints a truncated line of environment variables, similarly to the way I had originally defined in the unit file.

@Flameborn commented on GitHub (Feb 10, 2019): According to [this](https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html), the Environment directive allows a list of variable assignments, separated by spaces. I've modified my unit file to have separate Environment directives, unfortunately, still no go. _systemctl show bitwarden_ prints a truncated line of environment variables, similarly to the way I had originally defined in the unit file.

GiteaMirror commented

2025-11-07 06:29:06 -06:00

@Flameborn commented on GitHub (Feb 10, 2019):

Found the issue.

According to the wiki, the --env directive can be omitted, however, this is only true if the environment variables are specified as arguments to the run command. As this was not the case for me, since I had the directives in the unit file, along with specified -e directives as well, adding --env passed them along, as it is documented [here](https://github.com/ibuildthecloud/systemd-docker]

@Flameborn commented on GitHub (Feb 10, 2019): Found the issue. According to [the wiki](https://github.com/dani-garcia/bitwarden_rs/wiki/Running-with-systemd-docker), the _--env_ directive can be omitted, however, this is only true if the environment variables are specified as arguments to the run command. As this was not the case for me, since I had the directives in the unit file, along with specified _-e_ directives as well, adding _--env_ passed them along, as it is documented [here](https://github.com/ibuildthecloud/systemd-docker]