Camera not found in docker container

deekerman commented

2026-02-28 00:57:44 -05:00

Owner

Originally created by @MittaAxt on GitHub (Feb 24, 2021).

HI all

I'm running an RPI3 B+ with the NV camera with motioneyeOS and wanted to start over completely. So I erased everything and installed raspberry OS lite on my SD card 2 days ago, installed docker with the docker script and build the docker image as described here
https://github.com/ccrisan/motioneye/wiki/Install-In-Docker directly on the PI iteself.
The container starts and I can connect to the webui, but there is no camera to select.
I've checked from within the container and it seems (from my docker newbie point of view) that there is no camera present within the container, while the cam is recognized within the normal OS at least. (vcgencmd get_camera -> supported=1 detected=1)
the container is running under root permission (maybe not th best idea, but it was my first ever docker and container usage).
If I run vcgencmd get_camera from within the container I get VCHI initialization failed. Also raspistill from within the container is not working, while working within the normal OS.

Did I miss sth during the container build? Do I need addtitional parameters for the docker run?

Best regards

Originally created by @MittaAxt on GitHub (Feb 24, 2021). HI all I'm running an RPI3 B+ with the NV camera with motioneyeOS and wanted to start over completely. So I erased everything and installed raspberry OS lite on my SD card 2 days ago, installed docker with the docker script and build the docker image as described here https://github.com/ccrisan/motioneye/wiki/Install-In-Docker directly on the PI iteself. The container starts and I can connect to the webui, but there is no camera to select. I've checked from within the container and it seems (from my docker newbie point of view) that there is no camera present within the container, while the cam is recognized within the normal OS at least. (vcgencmd get_camera -> supported=1 detected=1) the container is running under root permission (maybe not th best idea, but it was my first ever docker and container usage). If I run vcgencmd get_camera from within the container I get VCHI initialization failed. Also raspistill from within the container is not working, while working within the normal OS. Did I miss sth during the container build? Do I need addtitional parameters for the docker run? Best regards

deekerman added the

question

docker

troubleshooting

labels

2026-02-28 00:57:44 -05:00

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@starbasessd commented on GitHub (Feb 24, 2021):

These instructions may help you:
https://www.losant.com/blog/how-to-access-the-raspberry-pi-camera-in-docker

@starbasessd commented on GitHub (Feb 24, 2021): These instructions may help you: https://www.losant.com/blog/how-to-access-the-raspberry-pi-camera-in-docker

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@MittaAxt commented on GitHub (Feb 24, 2021):

thank you for the link, as it describes the issue with permissions for the cam, but as the docker container is run by root, there should be no issue (in theory) according to the article. Or do I really need the additional rule to allow containers ,run by root, to acces the cam?
I've also tried to add the cam as --device=/dev/video0 or --device=/dev/vchiq, but the container won't start in that case.
Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "--device=/dev/vchiq": stat --device=/dev/vchiq: no such file or directory: unknown

@MittaAxt commented on GitHub (Feb 24, 2021): thank you for the link, as it describes the issue with permissions for the cam, but as the docker container is run by root, there should be no issue (in theory) according to the article. Or do I really need the additional rule to allow containers ,run by root, to acces the cam? I've also tried to add the cam as `--device=/dev/video0 `or `--device=/dev/vchiq`, but the container won't start in that case. `Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "--device=/dev/vchiq": stat --device=/dev/vchiq: no such file or directory: unknown`

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@starbasessd commented on GitHub (Feb 24, 2021):

I don't have a cable currently for my Pi3B+ and PiCam (CSI) so can't
reproduce the issue at this time.
Here's a somewhat different set of instructions. It would seem that you
need to -v some more folders, and add the udev rules as well as add the
camera device to go across the docker.
https://medium.com/swlh/how-to-access-the-raspberry-pi-camera-inside-docker-and-opencv-5fa25e092d91
This may be a case of not necessarily the best solution (using docker for a
CSI cam) but I'll try to help.

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Feb 24, 2021 at 7:55 AM berzerkwolf notifications@github.com
wrote:

thank you for the link, as it describes the issue with permissions for the
cam, but as the docker container is run by root, there should be no issue
(in theory) according to the article. Or do I really need the additional
rule to allow containers ,run by root, to acces the cam?
I've also tried to add the cam as --device=/dev/video0 or
--device=/dev/vchiq, but the container won't start in that case.
Error response from daemon: OCI runtime create failed:
container_linux.go:370: starting container process caused: exec:
"--device=/dev/vchiq": stat --device=/dev/vchiq: no such file or directory:
unknown

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785055118,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZTUHK75DPYFNVJTEI43M3TATZKLANCNFSM4YEIKUOQ
.

--
Thanks

Kevin Shumaker

Personal Tech Support https://kevinshumaker.wixsite.com/thethirdlevel

N38° 19' 56.52"
W85° 45' 8.56"

Semper Gumby
“Don't tell people how to do things. Tell them what to do and let them
surprise you with their results.” - G.S. Patton, Gen. USA
Ethics are what we do when no one else is looking.
Quis custodiet ipsos custodes?
“There is no end to the good you can do if you don’t care who
gets the credit.” - C Powell
You know we're sitting on four million pounds of fuel, one nuclear weapon
and a thing that has 270,000 moving parts built by the lowest bidder. Makes
you feel good, doesn't it?

@starbasessd commented on GitHub (Feb 24, 2021): I don't have a cable currently for my Pi3B+ and PiCam (CSI) so can't reproduce the issue at this time. Here's a somewhat different set of instructions. It would seem that you need to -v some more folders, and add the udev rules as well as add the camera device to go across the docker. https://medium.com/swlh/how-to-access-the-raspberry-pi-camera-inside-docker-and-opencv-5fa25e092d91 This may be a case of not necessarily the best solution (using docker for a CSI cam) but I'll try to help. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Feb 24, 2021 at 7:55 AM berzerkwolf <notifications@github.com> wrote: > thank you for the link, as it describes the issue with permissions for the > cam, but as the docker container is run by root, there should be no issue > (in theory) according to the article. Or do I really need the additional > rule to allow containers ,run by root, to acces the cam? > I've also tried to add the cam as --device=/dev/video0 or > --device=/dev/vchiq, but the container won't start in that case. > Error response from daemon: OCI runtime create failed: > container_linux.go:370: starting container process caused: exec: > "--device=/dev/vchiq": stat --device=/dev/vchiq: no such file or directory: > unknown > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785055118>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEZTUHK75DPYFNVJTEI43M3TATZKLANCNFSM4YEIKUOQ> > . > -- Thanks Kevin Shumaker Personal Tech Support <https://kevinshumaker.wixsite.com/thethirdlevel> N38° 19' 56.52" W85° 45' 8.56" Semper Gumby “Don't tell people how to do things. Tell them what to do and let them surprise you with their results.” - G.S. Patton, Gen. USA Ethics are what we do when no one else is looking. Quis custodiet ipsos custodes? “There is no end to the good you can do if you don’t care who gets the credit.” - C Powell You know we're sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it?

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@MittaAxt commented on GitHub (Feb 24, 2021):

OK thank you for all the help an all the links ..
luckily another link brought the solution. I had added the --device at the wrong position in the command -_- shame on me and my missing knowledge about docker.

docker run --name="motioneye" -p 8765:8765 --hostname="motioneye" -v /etc/localtime:/etc/localtime:ro -v /etc/motioneye:/etc/motioneye -v /var/lib/motioneye:/var/lib/motioneye --device /dev/vchiq --restart="always" --detach=true ccrisan/motioneye:master-armhf does work ..
I had the --device parameter after the containername, which means that this command was tried to be executed within the container itself, which does nothing.

Nevertheless I do not need the additional udev rules (if docker run by root) or the addtional /opt/vc path. (maybe that changes if I run as non-root)

One last question @starbasessd why do you think it is not a good idea to run the camera within the docker on the pi? I had planned to setup multiple cams with raspberry OS and docker and the same docker image and connect them to a central VM to detect motion and record the vidoes, so making the RPIs more or less stupid network cams.

@MittaAxt commented on GitHub (Feb 24, 2021): OK thank you for all the help an all the links .. luckily another link brought the solution. I had added the --device at the wrong position in the command -_- shame on me and my missing knowledge about docker. `docker run --name="motioneye" -p 8765:8765 --hostname="motioneye" -v /etc/localtime:/etc/localtime:ro -v /etc/motioneye:/etc/motioneye -v /var/lib/motioneye:/var/lib/motioneye --device /dev/vchiq --restart="always" --detach=true ccrisan/motioneye:master-armhf` does work .. I had the --device parameter after the containername, which means that this command was tried to be executed within the container itself, which does nothing. Nevertheless I do not need the additional udev rules (if docker run by root) or the addtional /opt/vc path. (maybe that changes if I run as non-root) One last question @starbasessd why do you think it is not a good idea to run the camera within the docker on the pi? I had planned to setup multiple cams with raspberry OS and docker and the same docker image and connect them to a central VM to detect motion and record the vidoes, so making the RPIs more or less stupid network cams.

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@starbasessd commented on GitHub (Feb 24, 2021):

As to the first part, you are adding another layer to an OS.
Motion/motionEye directly on RaspberryPiOS Lite is already starting to do
'layer on layer.
Docker on RaspberryPiOS is layer on layer (VM hypervisor on OS)
motionEye on Docker is layer on layer on layer (vm on vm hypervisor on OS)

I use a PiZeroW running motionEyeOS with a PiCam running in Fast Network
Camera mode and it effectively runs as a 'stupid network camera', but
because in FNC mose, all it does is stream, no processing for motion or
things.
I am playing with Docker, VirtualBox, and KVM in Linux. Each can be nice
solution if you don't have much Iron to run on, or want to sandbox stuff,
but IMO (and my opinion only) it's overkill for the setup you are looking
at.
Each machine (camera machine and hub) can run essentially the same image.
Camera machines with the Fast Network Camera turned on, and the hub running
'normally'.

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Feb 24, 2021 at 8:43 AM berzerkwolf notifications@github.com
wrote:

OK thank you for all the help an all the links ..
luckily another link brought the solution. I had added the --device at the
wrong position in the command -_- shame on me and my missing knowledge
about docker.

docker run --name="motioneye" -p 8765:8765 --hostname="motioneye" -v
/etc/localtime:/etc/localtime:ro -v /etc/motioneye:/etc/motioneye -v
/var/lib/motioneye:/var/lib/motioneye --device /dev/vchiq
--restart="always" --detach=true ccrisan/motioneye:master-armhf does work
..
I had the --device parameter after the containername, which means that
this command was tried to be executed within the container itself, which
does nothing.

Nevertheless I do not need the additional udev rules (if run be root) or
the addtional /opt/vc path. (maybe that changes if I run as non-root)

One last question @starbasessd https://github.com/starbasessd why do
you think it is not a good idea to run the camera within the docker on the
pi? I had planned to setup multiple cams with raspberry OS and docker and
the same docker image and connect them to a central VM to detect motion and
record the vidoes, so making the RPIs more or less stupid network cams.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785084087,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZTUHMRM5ALGPHRETFHQ7TTAT67XANCNFSM4YEIKUOQ
.

--
Thanks

Kevin Shumaker

Personal Tech Support https://kevinshumaker.wixsite.com/thethirdlevel

N38° 19' 56.52"
W85° 45' 8.56"

Semper Gumby
“Don't tell people how to do things. Tell them what to do and let them
surprise you with their results.” - G.S. Patton, Gen. USA
Ethics are what we do when no one else is looking.
Quis custodiet ipsos custodes?
“There is no end to the good you can do if you don’t care who
gets the credit.” - C Powell
You know we're sitting on four million pounds of fuel, one nuclear weapon
and a thing that has 270,000 moving parts built by the lowest bidder. Makes
you feel good, doesn't it?

@starbasessd commented on GitHub (Feb 24, 2021): As to the first part, you are adding another layer to an OS. Motion/motionEye directly on RaspberryPiOS Lite is already starting to do 'layer on layer. Docker on RaspberryPiOS is layer on layer (VM hypervisor on OS) motionEye on Docker is layer on layer on layer (vm on vm hypervisor on OS) I use a PiZeroW running motionEyeOS with a PiCam running in Fast Network Camera mode and it effectively runs as a 'stupid network camera', but because in FNC mose, all it does is stream, no processing for motion or things. I am playing with Docker, VirtualBox, and KVM in Linux. Each can be nice solution if you don't have much Iron to run on, or want to sandbox stuff, but IMO (and my opinion only) it's overkill for the setup you are looking at. Each machine (camera machine and hub) can run essentially the same image. Camera machines with the Fast Network Camera turned on, and the hub running 'normally'. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Feb 24, 2021 at 8:43 AM berzerkwolf <notifications@github.com> wrote: > OK thank you for all the help an all the links .. > luckily another link brought the solution. I had added the --device at the > wrong position in the command -_- shame on me and my missing knowledge > about docker. > > docker run --name="motioneye" -p 8765:8765 --hostname="motioneye" -v > /etc/localtime:/etc/localtime:ro -v /etc/motioneye:/etc/motioneye -v > /var/lib/motioneye:/var/lib/motioneye --device /dev/vchiq > --restart="always" --detach=true ccrisan/motioneye:master-armhf does work > .. > I had the --device parameter after the containername, which means that > this command was tried to be executed within the container itself, which > does nothing. > > Nevertheless I do not need the additional udev rules (if run be root) or > the addtional /opt/vc path. (maybe that changes if I run as non-root) > > One last question @starbasessd <https://github.com/starbasessd> why do > you think it is not a good idea to run the camera within the docker on the > pi? I had planned to setup multiple cams with raspberry OS and docker and > the same docker image and connect them to a central VM to detect motion and > record the vidoes, so making the RPIs more or less stupid network cams. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785084087>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEZTUHMRM5ALGPHRETFHQ7TTAT67XANCNFSM4YEIKUOQ> > . > -- Thanks Kevin Shumaker Personal Tech Support <https://kevinshumaker.wixsite.com/thethirdlevel> N38° 19' 56.52" W85° 45' 8.56" Semper Gumby “Don't tell people how to do things. Tell them what to do and let them surprise you with their results.” - G.S. Patton, Gen. USA Ethics are what we do when no one else is looking. Quis custodiet ipsos custodes? “There is no end to the good you can do if you don’t care who gets the credit.” - C Powell You know we're sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it?

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@MittaAxt commented on GitHub (Feb 24, 2021):

thank you for your view, but why would anyone run motioneye on docker then? what would be the benefits in this case, if it just adds layers?

@MittaAxt commented on GitHub (Feb 24, 2021): thank you for your view, but why would anyone run motioneye on docker then? what would be the benefits in this case, if it just adds layers?

deekerman commented

2026-02-28 00:57:47 -05:00

Author

Owner

@starbasessd commented on GitHub (Feb 24, 2021):

Like I said, it's handy when you don't have a lot of iron (available PCs)
to run it on.
For example, I have a Ryzen 7 with 32GB RAM and 10TB local storage (and
access to more)
I run a bunch of VBox, and dockers running on it (and now starting some KVM
development)
because I only have a handful of PCs and SBCs I can dedicate to those
processes. The docker images
aren't as friendly to use as compared to 'normal' apps or images, but lets
me run lots of test environments.
I have a number of SBCs (all the Pis except the Compute modules and the
400) and I notice a BIG difference
in performance when running even RPiOS with motion/motionEye vs running the
docker image.
Back in the day (VBox 4.x) I ran WinXP with VBox running WinXP with VBox,
with Linuxes. Why?
Because I could. Was it productive? Nope.
Ditto with docker on SBCs. If your docker app doesn't need much resources,
will be better than nothing, but
the Pis are so cheap (relative to a PC). However, motion/motionEye are very
resource intensive (CPU & GPU)
that you'll probably notice a frame rate reduction over motionEyeOS.

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Feb 24, 2021 at 9:12 AM berzerkwolf notifications@github.com
wrote:

thank you for your view, but why would anyone run motioneye on docker
then? what would be the benefits in this case, if it just adds layers?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785103169,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZTUHLGSEQ455LB5UH2SKLTAUCNPANCNFSM4YEIKUOQ
.

--
Thanks

Kevin Shumaker

Personal Tech Support https://kevinshumaker.wixsite.com/thethirdlevel

N38° 19' 56.52"
W85° 45' 8.56"

Semper Gumby
“Don't tell people how to do things. Tell them what to do and let them
surprise you with their results.” - G.S. Patton, Gen. USA
Ethics are what we do when no one else is looking.
Quis custodiet ipsos custodes?
“There is no end to the good you can do if you don’t care who
gets the credit.” - C Powell
You know we're sitting on four million pounds of fuel, one nuclear weapon
and a thing that has 270,000 moving parts built by the lowest bidder. Makes
you feel good, doesn't it?

@starbasessd commented on GitHub (Feb 24, 2021): Like I said, it's handy when you don't have a lot of iron (available PCs) to run it on. For example, I have a Ryzen 7 with 32GB RAM and 10TB local storage (and access to more) I run a bunch of VBox, and dockers running on it (and now starting some KVM development) because I only have a handful of PCs and SBCs I can dedicate to those processes. The docker images aren't as friendly to use as compared to 'normal' apps or images, but lets me run lots of test environments. I have a number of SBCs (all the Pis except the Compute modules and the 400) and I notice a BIG difference in performance when running even RPiOS with motion/motionEye vs running the docker image. Back in the day (VBox 4.x) I ran WinXP with VBox running WinXP with VBox, with Linuxes. Why? Because I could. Was it productive? Nope. Ditto with docker on SBCs. If your docker app doesn't need much resources, will be better than nothing, but the Pis are so cheap (relative to a PC). However, motion/motionEye are very resource intensive (CPU & GPU) that you'll probably notice a frame rate reduction over motionEyeOS. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Feb 24, 2021 at 9:12 AM berzerkwolf <notifications@github.com> wrote: > thank you for your view, but why would anyone run motioneye on docker > then? what would be the benefits in this case, if it just adds layers? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/ccrisan/motioneye/issues/2040#issuecomment-785103169>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEZTUHLGSEQ455LB5UH2SKLTAUCNPANCNFSM4YEIKUOQ> > . > -- Thanks Kevin Shumaker Personal Tech Support <https://kevinshumaker.wixsite.com/thethirdlevel> N38° 19' 56.52" W85° 45' 8.56" Semper Gumby “Don't tell people how to do things. Tell them what to do and let them surprise you with their results.” - G.S. Patton, Gen. USA Ethics are what we do when no one else is looking. Quis custodiet ipsos custodes? “There is no end to the good you can do if you don’t care who gets the credit.” - C Powell You know we're sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it?

Rows
Columns

Camera not found in docker container #1895