Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buildah bud fails silently when copying file to volume when root #5884

Open
mparada-suva opened this issue Dec 18, 2024 · 6 comments
Open

buildah bud fails silently when copying file to volume when root #5884

mparada-suva opened this issue Dec 18, 2024 · 6 comments

Comments

@mparada-suva
Copy link

Description

When copying a local file to a folder declared as a volume in an image using buildah bud as the root user the copy command is silently ignored.

Version

Output of buildah --version: buildah version 1.33.7 (image-spec 1.1.0-rc.5, runtime-spec 1.1.0)
Unfortunately can't update, since this is the newest available version I get from RedHat.

To reproduce

  • Have the following files locally available:

Dockerfile

FROM  jenkins/jenkins:2.490
USER root
RUN chgrp -R root /var/jenkins_home/
COPY foo.txt /var/jenkins_home
RUN cat /var/jenkins_home/foo.txt

foo.txt

just a test file

Note that the /var/jenkins_home folder is declared as a volume in the FROM image. If the same was done, say with the /tmp folder COPY would work.

  • Build with buildah bud: buildah bud -t test .

Result

STEP 1/5: FROM jenkins/jenkins:2.490
STEP 2/5: USER root
STEP 3/5: RUN chgrp -R root /var/jenkins_home/
STEP 4/5: COPY foo.txt /var/jenkins_home
STEP 5/5: RUN cat /var/jenkins_home/foo.txt
cat: /var/jenkins_home/foo.txt: No such file or directory
Error: building at STEP "RUN cat /var/jenkins_home/foo.txt": while running runtime: exit status 1

Expected result

I would expect one of the following behaviors (in order of preference):

  • COPY fails with an error that says you can't copy to a volume (since it would be overwritten once a volume is actually mounted there)
  • COPY outputs a warning saying whatever you copy to a volume will be overwritten on mount. But allows the copy to work. This would be acceptable if one knows the file is only needed at build time and can be overwritten at runtime. Looks like a footgun but at least it's a warning.
  • COPY silently works. Bigger footgun, but still acceptable.

What I don't think it is acceptable is to silently fail the COPY and simply continue building the next step.

Or maybe I'm doing something wrong 😅 If that is the case, please point me in the right direction!

@rhatdan
Copy link
Member

rhatdan commented Dec 18, 2024

What version of RHEL is this?

Is /var/jenkens_home a volume? If yes could you copy the file to /tmp and see if it shows up?

@mparada-suva
Copy link
Author

Thank you for the answer! I am on RHEL 9.4. I tried copying to /tmp and it works.

@rhatdan
Copy link
Member

rhatdan commented Dec 19, 2024

I am guessing /var/jenkens_home is a volume and the file is being copied but the next Run command is not seeing the copied file. In the cast of /tmp, then there is no VOLUME defined.

podman image inspect jenkins/jenkins:2.490

Should show you the defined volumes.

@mparada-suva
Copy link
Author

Yep! That is exactly why I mentioned it only is a bug when copying to a volume. I only think it is a bug because I would expect buildah to throw an error or warning when trying to copy something into a volume. If this is the intended behavior, then we can simply close this issue.

@rhatdan
Copy link
Member

rhatdan commented Dec 19, 2024

I don't know what is intended here? When you run the final build contianer, does the file show up in the volume or not, if not then I would say this is a bug. Although we could fall back to what does Docker do?

@flouthoc @nalind thoughts?

@nalind
Copy link
Member

nalind commented Jan 6, 2025

We turned off the "freezing" of volume directories during the build as the default behavior in 1.37, with a --compat-volumes CLI flag and corresponding API flag to select the older behavior. The PR (#5604) that changed it links to a couple of other issues where people were likewise surprised by the older behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants