I am trying to make it possible to make and mount loop devices from within a container. This happens to work on my own development system, but is failing to work on our build server where it must be done for an automated build.

I am ensuring that I'm starting the container as privileged. My container start line: docker run --privileged -it --rm <my_build_image>:latest /bin/bash. From within the container I try the following steps from the losetup man page:

# dd if=/dev/zero of=/var/tmp/file.img bs=1024k count=4
# losetup --show --find /var/tmp/file.img

This should provide me the next unused loop device and have associated it to /dev/loopn. However, instead I'm presented with the following (and showing that the loop module is loaded and /dev/loop-control is present):

[root@64a3a6900e0d /]# losetup --show --find /var/tmp/file.img
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop`.)
[root@64a3a6900e0d /]# ls /dev/loop*
[root@64a3a6900e0d /]# lsmod | grep loop
loop                   28072  0

On my own dev box, this works. I loaded loop and started the container as privileged and was able to make loop devices. What should I check for now?

  • The more important question is why do you want to make and mount loop devices. The whole point of a container is that the image is fixed and stateless, if you need stateful storage, you use a docker volume. If you want to to use a file as a volume inside the container, you probably have a use case where you shouldn't use a container in the first place. But it's impossible to tell without you describing the complete use case.
    – dirkt
    Commented May 28, 2022 at 5:04
  • @dirkt I completely agree with you! The short answer is: the needs of business (the enterprise) trump making it "right." I want to rework this build to eliminate the use of chroot (the reason for loop devices). The build was put together by someone who isn't with the team now, and we didn't use Docker then. He made it work nicely, but much of the assumptions no longer apply. A good question. Commented May 31, 2022 at 16:02

1 Answer 1


I have a solution to the problem. Some of the issue is that, although I'm not a docker neophyte, I am not a well seasoned user of docker yet. I think that when the container is spawned the /dev directory that existed at that point is somehow mapped into the container. I thought it was a "real-time" depiction of the /dev directory but this is not the case. If there were no /dev/loop# files none were permitted to exist even if the container was privileged.

So, the solution is that in the Jenkins pipeline, before the container is spawned, there is a stage which arranges for a /dev/loop# file to be made. Then, the container is spawned and a /dev/loop# is available.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .