buildah: "docker build" succeeds but "buildah build" fails with "mv: cannot move"

Description

docker build -t test . succeeds but buildah build -t test . fails with

mv: cannot move '/etc/bind' to '/srv/conf/etc/': No such file or directory
error building at STEP "RUN mv /etc/bind /srv/conf/etc/": error while running runtime: exit status 1

Steps to reproduce the issue:

Create a directory and cd into it
```
$ mkdir ~/test
$ cd ~/test
```

Create the file ~/test/Dockerfile with this contents

FROM ubuntu:jammy
VOLUME ["/srv"]
RUN mkdir -p /srv/conf/etc
RUN mkdir -p /etc/bind
RUN mv /etc/bind /srv/conf/etc/

Try to build the container image

$ buildah build -t test .
STEP 1/5: FROM ubuntu:jammy
Resolved "ubuntu" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/ubuntu:jammy...
Getting image source signatures
Copying blob 00f50047d606 done  
Copying config 21735dab04 done  
Writing manifest to image destination
Storing signatures
STEP 2/5: VOLUME ["/srv"]
STEP 3/5: RUN mkdir -p /srv/conf/etc
STEP 4/5: RUN mkdir -p /etc/bind
STEP 5/5: RUN mv /etc/bind /srv/conf/etc/
mv: cannot move '/etc/bind' to '/srv/conf/etc/': No such file or directory
error building at STEP "RUN mv /etc/bind /srv/conf/etc/": error while running runtime: exit status 1

Describe the results you received:

The command

buildah build -t test .

failed.

Describe the results you expected:

I expected the command

buildah build -t test .

to succeed.

Output of rpm -q buildah or apt list buildah:

buildah-1.27.0-1.fc37.aarch64

Output of buildah version:

Version:         1.27.0
Go Version:      go1.19
Image Spec:      1.0.2-dev
Runtime Spec:    1.0.2-dev
CNI Spec:        1.0.0
libcni Version:  v1.1.2
image Version:   5.22.0
Git Commit:      
Built:           Tue Aug  9 02:08:50 2022
OS/Arch:         linux/arm64
BuildPlatform:   linux/arm64/v8

Output of cat /etc/*release:

Fedora release 38 (Rawhide)
NAME="Fedora Linux"
VERSION="38.20220905.91.0 (CoreOS Prerelease)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora CoreOS 38.20220905.91.0"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
HOME_URL="https://getfedora.org/coreos/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/"
SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
VARIANT="CoreOS"
VARIANT_ID=coreos
OSTREE_VERSION='38.20220905.91.0'
Fedora release 38 (Rawhide)
Fedora release 38 (Rawhide)

Output of uname -a:

Linux localhost.localdomain 6.0.0-0.rc3.25.fc38.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 29 12:51:31 UTC 2022 aarch64 GNU/Linux

Output of cat /etc/containers/storage.conf:

cat /etc/containers/storage.conf
cat: /etc/containers/storage.conf: No such file or directory

Extra information

I downloaded fedora-coreos-38.20220905.91.0-qemu.aarch64.qcow2.xz from https://builds.coreos.fedoraproject.org/browser?stream=rawhide&arch=aarch64 and booted up the VM with qemu on a macbook pro. Buildah was installed with

rpm-ostree install --apply-live buildah

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 30 (20 by maintainers)

Most upvoted comments

Buildah currently handles VOLUME instructions in the same way as Docker’s classic (legacy) builder. The newer BuildKit behaves differently.

Quote: There’s a difference in how VOLUME instructions are handled between BuildKit and the classic builder. from: https://github.com/moby/moby/discussions/44104#discussioncomment-3593939 See also https://github.com/moby/moby/issues/3639#issuecomment-482098988

eriksjolund on Sep 9, 2022

I was under the impression that VOLUME was used to define an area where files can be modified and stored between every time the container is restarted as all other files will revert back to original if modified whenever the container is restarted.

Restarting a specific container does not modify the contents of volumes. Recreating the container, of course, gives the new container a fresh copy of whatever was in the image at that location.

I also was under the impression that VOLUME had to be defined in the beginning of the Dockerfile, but if the directory is “frozen” when defined and VOLUME can be called anywhere in Dockerfile, then I could just do all my file movements first and then use VOLUME.

This is generally what I’d recommend.

nalind on Sep 7, 2022

The VOLUME instruction “freezes” the contents of the named directory so that it can only be subsequently modified with ADD or COPY. Any effects that RUN instructions that come after VOLUME have on the directory are discarded immediately, so the destination for the “mv” command does not exist. When I try to build that Dockerfile with an empty build context using moby-engine-20.10.17-5.fc36.x86_64, it also fails at the same spot for the same reason (verified by RUNning “find /srv -ls” right before). Are you using a different version of docker build?

When I try with DOCKER_BUILDKIT=1 in my environment, that first “mkdir” appears to be stopped by SELinux because “mv” is running as “container_t” and trying to write to a /srv that’s labeled as “container_ro_file_t”, which is not allowed. In permissive mode, it does appear that the volume’s contents aren’t being reset after RUN, which is surprising for me, and may be a bug.

nalind on Sep 6, 2022