Problem on docker run #249

New Issue

OVERLORD · 2026-02-04T18:57:23+03:00

OVERLORD commented

2026-02-04 18:57:23 +03:00

Originally created by @MarkOnDuty on GitHub (Mar 6, 2019).

My suspicion is the problem is with Docker or LXC/LXD, but I'll start here.

I'm trying to get a bitwarden_rs server up and running. Created a new LXD container, hopped into it, and did the following:

apt update
apt upgrade
curl -sSL https://get.docker.com | sh
mkdir /bw-data
docker pull mprasil/bitwarden:latest
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 mprasil/bitwarden:latest

No issues with all but the last command. Here's the result of the run:

d6423f3b25b35a18a530b4ea2629f745460d94b64e2b554d65653661f4f819e7
docker: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \"rootfs_linux.go:58: mounting \\\"proc\\\" to rootfs \\\"/var/lib/docker/vfs/dir/428b63304ee65c84c9962aa1d6df8d919a7f931ba914ed73963af3ee416951d0\\\" at \\\"/proc\\\" caused \\\"permission denied\\\"\"": unknown.

Any ideas? Or should I move up the chain and ask the Docker or LXC/LXD people?

Originally created by @MarkOnDuty on GitHub (Mar 6, 2019). My suspicion is the problem is with Docker or LXC/LXD, but I'll start here. I'm trying to get a bitwarden_rs server up and running. Created a new LXD container, hopped into it, and did the following: ``` apt update apt upgrade curl -sSL https://get.docker.com | sh mkdir /bw-data docker pull mprasil/bitwarden:latest docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 mprasil/bitwarden:latest ``` No issues with all but the last command. Here's the result of the run: ``` d6423f3b25b35a18a530b4ea2629f745460d94b64e2b554d65653661f4f819e7 docker: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \"rootfs_linux.go:58: mounting \\\"proc\\\" to rootfs \\\"/var/lib/docker/vfs/dir/428b63304ee65c84c9962aa1d6df8d919a7f931ba914ed73963af3ee416951d0\\\" at \\\"/proc\\\" caused \\\"permission denied\\\"\"": unknown. ``` Any ideas? Or should I move up the chain and ask the Docker or LXC/LXD people?

OVERLORD added the question label 2026-02-04 18:57:23 +03:00

OVERLORD closed this issue

2026-02-04 18:57:31 +03:00

OVERLORD commented

2026-02-04 18:57:42 +03:00

@dani-garcia commented on GitHub (Mar 6, 2019):

It mentions a permission issue, so I can think of two possible causes:

The user running docker doesn't have permission to create the /bw-data folder.
The port needs to be changed to something > 1024, because the others are privileged ports.

I'd try changing the command to -p 8080:80 and creating the /bw-data folder manually, to see if that helps.

@dani-garcia commented on GitHub (Mar 6, 2019): It mentions a permission issue, so I can think of two possible causes: - The user running docker doesn't have permission to create the `/bw-data` folder. - The port needs to be changed to something > 1024, because the others are privileged ports. I'd try changing the command to `-p 8080:80` and creating the `/bw-data` folder manually, to see if that helps.

OVERLORD commented

2026-02-04 18:57:52 +03:00

@mprasil commented on GitHub (Mar 6, 2019):

I believe this is Docker in LXC/LXD issue. You can rule out bitwarden_rs being the problematic part by running alpine for example: docker run -ti --rm alpine and seeing if that works fine. (ctrl+d to exit the container if it runs fine)

If LCX configuration is really the problem, I have somewhat similar setup and the LXC container needs to be started with some extra privileges to be able to run containers inside. The way I do that is I create a LXC profile with following config:

config:
  linux.kernel_modules: bridge,br_netfilter,ip_tables,ip6_tables,ip_vs,netlink_diag,nf_nat,overlay,xt_conntrack
  raw.lxc: |-
    lxc.cgroup.devices.allow = a
    lxc.cap.drop =
  security.nesting: "true"
  security.privileged: "true"
description: Privileged privileged docker capable profile
devices:
  aadisable:
    path: /sys/module/apparmor/parameters/enabled
    source: /dev/null
    type: disk
name: docker

I think you might be able to set it a bit more strict, but this is what worked for me. Then you just assign that profile to your new LXC container and you should be able to run containers inside.

@mprasil commented on GitHub (Mar 6, 2019): I believe this is Docker in LXC/LXD issue. You can rule out `bitwarden_rs` being the problematic part by running `alpine` for example: `docker run -ti --rm alpine` and seeing if that works fine. (`ctrl+d` to exit the container if it runs fine) If LCX configuration is really the problem, I have somewhat similar setup and the LXC container needs to be started with some extra privileges to be able to run containers inside. The way I do that is I create a LXC profile with following config: ```yaml config: linux.kernel_modules: bridge,br_netfilter,ip_tables,ip6_tables,ip_vs,netlink_diag,nf_nat,overlay,xt_conntrack raw.lxc: |- lxc.cgroup.devices.allow = a lxc.cap.drop = security.nesting: "true" security.privileged: "true" description: Privileged privileged docker capable profile devices: aadisable: path: /sys/module/apparmor/parameters/enabled source: /dev/null type: disk name: docker ``` I think you might be able to set it a bit more strict, but this is what worked for me. Then you just assign that profile to your new LXC container and you should be able to run containers inside.

OVERLORD commented

2026-02-04 18:57:56 +03:00

@MarkOnDuty commented on GitHub (Mar 6, 2019):

That got 'em. Thanks.

Of course, that profile sets the network up a little differently than I need, but that's my problem to solve.

@MarkOnDuty commented on GitHub (Mar 6, 2019): That got 'em. Thanks. Of course, that profile sets the network up a little differently than I need, but that's my problem to solve.

OVERLORD commented

2026-02-04 18:58:06 +03:00

@MarkOnDuty commented on GitHub (Mar 6, 2019):

Modified the profile to have a bridged eth0 device and I can now access the web interface from elsewhere:

config:
  linux.kernel_modules: bridge,br_netfilter,ip_tables,ip6_tables,ip_vs,netlink_diag,nf_nat,overlay,xt_conntrack
  raw.lxc: |-
    lxc.cgroup.devices.allow = a
    lxc.cap.drop =
  security.nesting: "true"
  security.privileged: "true"
description: Privileged privileged docker capable profile
devices:
  aadisable:
    path: /sys/module/apparmor/parameters/enabled
    source: /dev/null
    type: disk
  eth0:
    name: eth0
    nictype: bridged
    parent: br2
    type: nic
name: docker
used_by: []

I can probably remove some of the kernel modules too.

@MarkOnDuty commented on GitHub (Mar 6, 2019): Modified the profile to have a bridged eth0 device and I can now access the web interface from elsewhere: ``` config: linux.kernel_modules: bridge,br_netfilter,ip_tables,ip6_tables,ip_vs,netlink_diag,nf_nat,overlay,xt_conntrack raw.lxc: |- lxc.cgroup.devices.allow = a lxc.cap.drop = security.nesting: "true" security.privileged: "true" description: Privileged privileged docker capable profile devices: aadisable: path: /sys/module/apparmor/parameters/enabled source: /dev/null type: disk eth0: name: eth0 nictype: bridged parent: br2 type: nic name: docker used_by: [] ``` I can probably remove some of the kernel modules too.

OVERLORD commented

2026-02-04 18:58:14 +03:00

@mprasil commented on GitHub (Mar 6, 2019):

Ah sorry, I forgot to mention that you might need to move some of the settings to different profile or merge them. (like you did)

I'm actually using multiple profiles. This one holds docker specific settings, I had another one that sets the bridge similar to your setup.

@mprasil commented on GitHub (Mar 6, 2019): Ah sorry, I forgot to mention that you might need to move some of the settings to different profile or merge them. (like you did) I'm actually using multiple profiles. This one holds docker specific settings, I had another one that sets the bridge similar to your setup.

OVERLORD commented

2026-02-04 18:58:20 +03:00

@MarkOnDuty commented on GitHub (Mar 6, 2019):

No worries. You nudged me in the right direction. It only took a couple of minutes from that point. You have my gratitude. For that matter, the fact that I've now got this (mostly) running has me thinking about donating to the project (as well as upstream). Assuming that we end up using this more broadly, I've got some budget to allocate in that direction.

Seriously, any options for keeping this project (and upstream) healthy are worth sharing. (And I've read the wiki page on supporting upstream. It's great to see some effort towards that.)

@MarkOnDuty commented on GitHub (Mar 6, 2019): No worries. You nudged me in the right direction. It only took a couple of minutes from that point. You have my gratitude. For that matter, the fact that I've now got this (mostly) running has me thinking about donating to the project (as well as upstream). Assuming that we end up using this more broadly, I've got some budget to allocate in that direction. Seriously, any options for keeping this project (and upstream) healthy are worth sharing. (And I've read the wiki page on supporting upstream. It's great to see some effort towards that.)

OVERLORD commented

2026-02-04 18:58:24 +03:00

@mprasil commented on GitHub (Mar 6, 2019):

Glad you got it working. We have a wiki page with info if you want to support upstream.

@mprasil commented on GitHub (Mar 6, 2019): Glad you got it working. We have a wiki page with info if you want to [support upstream](https://github.com/dani-garcia/bitwarden_rs/wiki/Supporting-upstream).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#249