[Unit]
Description=Bitwarden Server (Rust Edition)
Documentation=https://github.com/dani-garcia/bitwarden_rs
After=network.target
[Service]
# The user/group bitwarden_rs is run under. the working directory (see below) should allow write and read access to this user/group
User=bitwarden_rs
Group=bitwarden_rs
# The location of the .env file for configuration
EnvironmentFile=/home/bitwarden_rs/.env
# The location of the compiled binary
ExecStart=/home/bitwarden_rs/bitwarden_rs
# Set reasonable connection and process limits
LimitNOFILE=1048576
LimitNPROC=64
# Isolate bitwarden_rs from the rest of the system
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict
# Only allow writes to the following directory and set it to the working directory (user and password data are stored here)
WorkingDirectory=/home/bitwarden_rs
ReadWriteDirectories=/home/bitwarden_rs
# Allow bitwarden_rs to bind ports in the range of 0-1024
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
I got with systemctl status bitwarden_rs:
● bitwarden_rs.service - Bitwarden Server (Rust Edition)
Loaded: loaded (/etc/systemd/system/bitwarden_rs.service; disabled)
Active: failed (Result: exit-code) since Wed 2019-01-23 20:04:20 GMT; 12s ago
Docs: https://github.com/dani-garcia/bitwarden_rs
Process: 14005 ExecStart=/home/bitwarden_rs/bitwarden_rs (code=exited, status=226/NAMESPACE)
Main PID: 14005 (code=exited, status=226/NAMESPACE)
Jan 23 20:04:20 geob-vps systemd[1]: Started Bitwarden Server (Rust Edition).
Jan 23 20:04:20 geob-vps systemd[1]: bitwarden_rs.service: main process exited, code=exited, status=226/NAMESPACE
Jan 23 20:04:20 geob-vps systemd[1]: Unit bitwarden_rs.service entered failed state.
with journalctl -u bitwarden_rs.service
Jan 23 20:04:18 geob-vps systemd[1]: [/etc/systemd/system/bitwarden_rs.service:21] Failed to parse protect system value, ignoring: strict
Jan 23 20:04:18 geob-vps systemd[1]: [/etc/systemd/system/bitwarden_rs.service:26] Unknown lvalue 'AmbientCapabilities' in section 'Service'
Jan 23 20:04:20 geob-vps systemd[1]: Starting Bitwarden Server (Rust Edition)...
Jan 23 20:04:20 geob-vps systemd[1]: Started Bitwarden Server (Rust Edition).
Jan 23 20:04:20 geob-vps systemd[1]: bitwarden_rs.service: main process exited, code=exited, status=226/NAMESPACE
Jan 23 20:04:20 geob-vps systemd[1]: Unit bitwarden_rs.service entered failed state.
and in /var/log/syslog I can see:
Failed at step NAMESPACE spawning /home/bitwarden_rs/bitwarden_rs: Permission denied
What am I missing?
Originally created by @Geobert on GitHub (Jan 23, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/363
With this .service file:
```
[Unit]
Description=Bitwarden Server (Rust Edition)
Documentation=https://github.com/dani-garcia/bitwarden_rs
After=network.target
[Service]
# The user/group bitwarden_rs is run under. the working directory (see below) should allow write and read access to this user/group
User=bitwarden_rs
Group=bitwarden_rs
# The location of the .env file for configuration
EnvironmentFile=/home/bitwarden_rs/.env
# The location of the compiled binary
ExecStart=/home/bitwarden_rs/bitwarden_rs
# Set reasonable connection and process limits
LimitNOFILE=1048576
LimitNPROC=64
# Isolate bitwarden_rs from the rest of the system
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict
# Only allow writes to the following directory and set it to the working directory (user and password data are stored here)
WorkingDirectory=/home/bitwarden_rs
ReadWriteDirectories=/home/bitwarden_rs
# Allow bitwarden_rs to bind ports in the range of 0-1024
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
```
I got with `systemctl status bitwarden_rs`:
```
● bitwarden_rs.service - Bitwarden Server (Rust Edition)
Loaded: loaded (/etc/systemd/system/bitwarden_rs.service; disabled)
Active: failed (Result: exit-code) since Wed 2019-01-23 20:04:20 GMT; 12s ago
Docs: https://github.com/dani-garcia/bitwarden_rs
Process: 14005 ExecStart=/home/bitwarden_rs/bitwarden_rs (code=exited, status=226/NAMESPACE)
Main PID: 14005 (code=exited, status=226/NAMESPACE)
Jan 23 20:04:20 geob-vps systemd[1]: Started Bitwarden Server (Rust Edition).
Jan 23 20:04:20 geob-vps systemd[1]: bitwarden_rs.service: main process exited, code=exited, status=226/NAMESPACE
Jan 23 20:04:20 geob-vps systemd[1]: Unit bitwarden_rs.service entered failed state.
```
with `journalctl -u bitwarden_rs.service`
```
Jan 23 20:04:18 geob-vps systemd[1]: [/etc/systemd/system/bitwarden_rs.service:21] Failed to parse protect system value, ignoring: strict
Jan 23 20:04:18 geob-vps systemd[1]: [/etc/systemd/system/bitwarden_rs.service:26] Unknown lvalue 'AmbientCapabilities' in section 'Service'
Jan 23 20:04:20 geob-vps systemd[1]: Starting Bitwarden Server (Rust Edition)...
Jan 23 20:04:20 geob-vps systemd[1]: Started Bitwarden Server (Rust Edition).
Jan 23 20:04:20 geob-vps systemd[1]: bitwarden_rs.service: main process exited, code=exited, status=226/NAMESPACE
Jan 23 20:04:20 geob-vps systemd[1]: Unit bitwarden_rs.service entered failed state.
```
and in `/var/log/syslog` I can see:
```
Failed at step NAMESPACE spawning /home/bitwarden_rs/bitwarden_rs: Permission denied
```
What am I missing?
Btw, in .env I have:
ROCKET_ADDRESS=127.0.0.1 # Enable this to test mobile app
ROCKET_PORT=8000
and ROCKET_TLS pointing to my certificate and key
<!-- gh-comment-id:456950254 -->
@Geobert commented on GitHub (Jan 23, 2019):
Btw, in `.env` I have:
ROCKET_ADDRESS=127.0.0.1 # Enable this to test mobile app
ROCKET_PORT=8000
and ROCKET_TLS pointing to my certificate and key
Try enabling the backports repository and updating systemd from there. I had a similar issue myself when setting up sandboxing.
Alternatively, you can remove most of the sandboxing options, as they aren't present in the version of systemd in debian 9 stable.
<!-- gh-comment-id:457020293 -->
@pgaskin commented on GitHub (Jan 24, 2019):
Try enabling the backports repository and updating systemd from there. I had a similar issue myself when setting up sandboxing.
Alternatively, you can remove most of the sandboxing options, as they aren't present in the version of systemd in debian 9 stable.
Thanks, I'll try that if I come back to bitwarden. I manage to launch with supervisord and was disappointed by the desktop client lack of Autofill and ssh agent :(
Let's close this issue for now :)
<!-- gh-comment-id:457126834 -->
@Geobert commented on GitHub (Jan 24, 2019):
Thanks, I'll try that if I come back to bitwarden. I manage to launch with supervisord and was disappointed by the desktop client lack of Autofill and ssh agent :(
Let's close this issue for now :)
<!-- gh-comment-id:457191814 -->
@Geobert commented on GitHub (Jan 24, 2019):
Are you sure? I've search a lot and stumble upon feature request: https://community.bitwarden.com/t/auto-type-autofill-for-logging-into-other-desktop-apps/158
Hi srry for the necro, this issue can remain closed, im posting my fix in case anyone also ended up in the same situation as me.
I'm running the service in a proxmox privileged lxc on debian 12 and also got this error:
vaultwarden.service: Failed to set up mount namespacing: Permission denied
vaultwarden.service: Failed at step NAMESPACE spawning /opt/vaultwarden/bin/vaultwarden: Permission denied
<!-- gh-comment-id:3336213347 -->
@ver-nyan commented on GitHub (Sep 25, 2025):
Hi srry for the necro, this issue can remain closed, im posting my fix in case anyone also ended up in the same situation as me.
I'm running the service in a proxmox privileged lxc on debian 12 and also got this error:
```
vaultwarden.service: Failed to set up mount namespacing: Permission denied
vaultwarden.service: Failed at step NAMESPACE spawning /opt/vaultwarden/bin/vaultwarden: Permission denied
```
It wasn't the security configs in the service file that was causing the error, but the `nesting` disabled in the lxc that cause it (since I set the container as privileged).
Enabling `nesting` back fixed it for me while keeping the same service configs (im using the service config from https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/vaultwarden-install.sh).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Geobert on GitHub (Jan 23, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/363
With this .service file:
I got with
systemctl status bitwarden_rs:with
journalctl -u bitwarden_rs.serviceand in
/var/log/syslogI can see:What am I missing?
@Geobert commented on GitHub (Jan 23, 2019):
Btw, in
.envI have:ROCKET_ADDRESS=127.0.0.1 # Enable this to test mobile app
ROCKET_PORT=8000
and ROCKET_TLS pointing to my certificate and key
@pgaskin commented on GitHub (Jan 24, 2019):
Try enabling the backports repository and updating systemd from there. I had a similar issue myself when setting up sandboxing.
Alternatively, you can remove most of the sandboxing options, as they aren't present in the version of systemd in debian 9 stable.
@Geobert commented on GitHub (Jan 24, 2019):
Thanks, I'll try that if I come back to bitwarden. I manage to launch with supervisord and was disappointed by the desktop client lack of Autofill and ssh agent :(
Let's close this issue for now :)
@pgaskin commented on GitHub (Jan 24, 2019):
Um, there is autofill. Go to the settings page and you can turn it on.
@Geobert commented on GitHub (Jan 24, 2019):
Are you sure? I've search a lot and stumble upon feature request: https://community.bitwarden.com/t/auto-type-autofill-for-logging-into-other-desktop-apps/158
@pgaskin commented on GitHub (Jan 24, 2019):
Oh, I thought you meant browser autofill, not desktop app autofill.
@ver-nyan commented on GitHub (Sep 25, 2025):
Hi srry for the necro, this issue can remain closed, im posting my fix in case anyone also ended up in the same situation as me.
I'm running the service in a proxmox privileged lxc on debian 12 and also got this error:
It wasn't the security configs in the service file that was causing the error, but the
nestingdisabled in the lxc that cause it (since I set the container as privileged).Enabling
nestingback fixed it for me while keeping the same service configs (im using the service config from https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/vaultwarden-install.sh).