/dev/mem no such file or directory in Ubuntu Linux 14.04 container

Issue: Try to run “dmidecode -s system-product-name”. Output returns "/dev/mem: No such file or directory"
Host OS: Ubuntu Linux 14.04, Kernel version 4.2.0-42-generic
Try to run command “dmidecode -s system-product-name”, which returns “/dev/mem: No such file or directory”.
Give me a solution.

dmidecode accesses extremely low-level data from the physical host system, and you probably just can’t run it from within a Docker container.

What’s your actual goal?

Did you try to share /dev/mem device , with docker run --device /dev/mem:/dev/mem --rm -it … ?

1 Like

Struggling with the usage of dmidecode as well. Absolutely zero problems in Ubuntu but once it’s wrapped in a docker, it’s broken. I have added the --device /dev/mem stuff to the run but still no luck. Does docker just not know how to handle /dev/mem or is there more configurations to add to the run than I already have?

Looks like dmidecode needs --privileged in the run command. --device /dev/mem is not needed.

I know this is several months old, but I had the same issue myself and was able to solve it without using “–privileged”. Might help someone else.

TL;DR: add the /dev/mem device and add the sys_rawio capability.

Long version (focused on security):

#dockerfile
FROM alpine@sha256:3d44fa76c2c83ed9296e4508b436ff583397cac0f4bad85c2b4ecc193ddb5106

    RUN apk --no-cache add \
            dmidecode 

# ...other configuration
#docker-compose
dmidecode:
 build: 
   #...build context, etc
 network_mode: "none"         # optional, more secure
 devices:                     # required
   - "/dev/mem:/dev/mem"
 cap_drop:                    # optional, more secure
   - ALL
 cap_add:                     # required
   - sys_rawio
 read_only: true              # optional, more secure

Because I can really only see dmidecode being used to spit out system information, I removed network access entirely.

I don’t know that much about dmidecode, but it’s possible you might need to mount other devices depending on what you’re doing. Maybe even capabilities. But I think it’s clear that with some trial and error, you can avoid using --privileged.

nice :grinning:–device /dev/mem:/dev/mem