"docker build -f FILE_NAME" requires full path to the file #14339

Closed
wzheng2310 opened this Issue Jul 1, 2015 · 53 comments

Projects

None yet
@wzheng2310

Hi,

When I run this from command line:
docker build -t XXX --file Dockerfile /full/path/to/directory/containing/the/given/dockerfile

I got this error:
The Dockerfile (Dockerfile) must be within the build context (/full/path/to/directory/containing/the/given/dockerfile/)

I have to give full path to the filename, i.e.:
docker build -t XXX --file /full/path/to/directory/containing/the/given/dockerfile/Dockerfile /full/path/to/directory/containing/the/given/dockerfile

This does not make much sense to me. The path to the directory (i.e. the build context) is already given, the file name should be assumed to be under that directory.

@wzheng2310

This is a duplicate of issue #11289.

@wzheng2310 wzheng2310 closed this Jul 1, 2015
@rrnewton

This is pretty unclear to me. Based on the above I'd expect absolute paths for both to work:

$ docker build -t XXX --file `pwd`/Dockerfile `pwd`

But that gives the same "must be within build context" error.

Likewise based on a literal interpretation of the "PATH/Docker" in the help message, it would seem that PATH=. would be ok, but I get the same error with:

$ docker build -t XXX --file ./Dockerfile .
@duglin
Contributor
duglin commented Aug 14, 2015

Do you use symlinks at all ?

-Doug

Sent from my iPhone

On Aug 14, 2015, at 1:48 PM, Ryan Newton notifications@github.com wrote:

This is pretty unclear to me. Based on the above I'd expect absolute paths for both to work:

$ docker build -t XXX --file pwd/Dockerfile pwd
But that gives the same "must be within build context" error.

Likewise based on a literal interpretation of the "PATH/Docker" in the help message, it would seem that PATH=. would be ok, but I get the same error with:

$ docker build -t XXX --file ./Dockerfile .

Reply to this email directly or view it on GitHub.

@rrnewton

Nope, no symlinks. Further, using the same project checkout out on a mac and linux machines I'm getting different behavior. Here's on my mac laptop:

$ docker --version
Docker version 1.8.1, build d12ea79
$ docker build -f Dockerfile .
unable to prepare context: The Dockerfile (/Users/.../Dockerfile) must be within the build context (.)

It's a frustrating error message to read because, grr, the Dockerfile is in the directory ..

Here's on the linux server:

$ docker --version
Docker version 1.7.1, build 786b29d
$ docker build -f Dockerfile .
Sending build context to Docker daemon 22.44 MB
... <works fine>

So maybe it's a 1.7-1.8 regression, or a problem with the Mac client.

@rrnewton

Update: same problem on Docker version 1.8.1, build d12ea79 on Linux.

@duglin
Contributor
duglin commented Aug 15, 2015

@rrnewton I can't reproduce it, using 'master' and 'd12ea79'. Are you sure there isn't anything special about your setup?

@p16
p16 commented Aug 16, 2015

Same problem here:

$ docker build -t test -f DockerfileTest .
unable to prepare context: The Dockerfile (/path/to/project/DockerfileTest) must be within the build context (.)

docker version: Docker version 1.8.1, build d12ea79 on ubuntu 14.04

@duglin
Contributor
duglin commented Aug 16, 2015

geez this is weird - I just can't reproduce this. Can someone make a tar or zip file available of a minimal dir structure?

@thaJeztah
Member

Wondering if all cases here are using a boot2docker setup and if that is related, also thinking things like OS X/Windows being case insensitive, whereas the Boot2Docker VM isn't. (I.e., I saw another (unrelated) example where c:\some\path didn't work, but C:\some\path did)

@duglin
Contributor
duglin commented Aug 16, 2015

could be a boot2docker issue, but I don't think its a case insensitive thing because then it would generate a "file not found" type of error instead.

@thaJeztah
Member

doh, yes, should've switched on my brain before posting. Still interested to see if all here are using a boot2docker setup.

@rrnewton

I was using boot2docker, but I aso got the same error on Linux with 1.8 but not 1.7.

@duglin
Contributor
duglin commented Aug 16, 2015

@rrnewton any chance you could send me a tar/zip of a test dir that shows this? And include a sh file showing the exact command you're using.

@ghudiczius

I'm experiencing a similar problem, even when using full path for both the context and the Dockerfile

$ docker build -t project/machine:latest --rm=true -f $(pwd)/conf/base/machine/latest.Dockerfile $(pwd)/conf
unable to prepare context: The Dockerfile (d:\path\to\docker\files\conf\base\machine\latest.Dockerfile) must be within the build context (d:/path/to/docker/files/conf)

Note that while the path for the Dockerfile uses backslashes the path to the context uses slashes
Also pwd actually returns /d/path/to/docker/files, not d:/path/to/docker/files neither d:\path\to\docker\files

This is on Windows 7 (64bit professional)

$ uname -a
MINGW32_NT-6.1 MACHINENAME 1.0.12(0.46/3/2) 2012-07-05 14:56 i686 unknown
$ docker version
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      windows/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      linux/amd64
$ docker -D info
Containers: 0
Images: 0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.0.9-boot2docker
Operating System: Boot2Docker 1.8.1 (TCL 6.3); master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
CPUs: 1
Total Memory: 1.956 GiB
Name: default
ID: UF45:XWKK:QGDY:G27T:IBXT:UZX2:7WYD:WFZK:YJXI:IKZB:57AI:IWZM
Debug mode (server): true
File Descriptors: 9
Goroutines: 16
System Time: 2015-08-18T09:43:49.241086399Z
EventsListeners: 0
Init SHA1:
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox
@mingfang

same problem using boot2docker.
build works in 1.7 but broken in 1.8.
qa anyone?

@wzheng2310

Someone mentioned (or is guessing) if this is boot2docker issue. I don't know about the others but for me I am not using boot2docker.

@duglin
Contributor
duglin commented Aug 20, 2015

just tried on a mac and I can't reproduce this.
does someone have time to send me a zip/tar of a test build that shows this? I mean do you guys really have nothing but a Dockerfile in the current dir and nothing else? no links, nada?

@mingfang

I created this repo to help reproduce the problem
https://github.com/mingfang/docker-test.git

On Aug 20, 2015, at 2:07 PM, Doug Davis notifications@github.com wrote:

just tried on a mac and I can't reproduce this.
does someone have time to send me a zip/tar of a test build that shows this? I mean do you guys really have nothing but a Dockerfile in the current dir and nothing else? no links, nada?


Reply to this email directly or view it on GitHub #14339 (comment).

@ghudiczius

steps to reproduce (windows 10, powershell):

cd /
mkdir -p docker-14339
cd docker-14339
mkdir test
echo "FROM busybox" > test/test.Dockerfile

cmd /c mklink /d link test

docker build -f test/test.Dockerfile test
docker build -f "$(pwd)/test/test.Dockerfile" "$(pwd)/test"

docker build -f link/test.Dockerfile link
docker build -f "$(pwd)/link/test.Dockerfile" "$(pwd)/link"

the first two docker build command works, the third and fourth ones don't

@duglin
Contributor
duglin commented Aug 20, 2015

@mingfang just tried it and it still works for me :-(
@ghudiczius not sure what the 'mklink' command does but links with builds are a bit funky. I don't think we process softlinks which means a softlink to a Dockerfile outside of the build context won't work.

@ghudiczius

mklink /d creates a directory symlink on windows (similar to ln -s)
the above setup worked just fine with 1.7 and boot2docker

also on windows, when using mingw bash (git bash) the whole c:, d:, etc partitions are translated somehow (not sure though how) into /c/, /d/, etc, and i receive the same error as i mentioned in my initial post, which makes the mingw shell (git shell) unusuable

@mingfang

I think I found the problem that I've been seeing.
It looks like the new boot2docker can only see files anywhere inside the home directory of the host;
It can not see files in /tmp, for example.

@duglin
Contributor
duglin commented Aug 24, 2015

ping @tianon

@MJ-Lee
MJ-Lee commented Aug 27, 2015

The same with @mingfang
I use a /tmp folder, get the same error.
Any follow up?

@thaJeztah
Member

looks like the new boot2docker can only see files anywhere inside the home directory of the host;

Actually, I think that's always been the case; only the "Users" directory is (by default) shared with the Boot2Docker VM (using VirtualBox guest additions), any directory outside of "Users" must be manually added as a VBox share. See https://github.com/boot2docker/boot2docker/blob/master/README.md#virtualbox-guest-additions

@MJ-Lee
MJ-Lee commented Aug 30, 2015

@thaJeztah
Actually, I am adding shared folder using command line:
VBoxManage sharedfolder add boot2docker-vm --name "Shared" --hostpath "folderInSystem"
and mount it inside boot2docker.
If there is a difference between using virtualbox guest additions and command line, I will let you know.
Otherwise, I will post a new issue.

@michaeljs1990

Same issue as everyone above.

  • Docker toolbox / boot2docker
  • Mac
  • using tmp directory

This had to be one of the more infuriating bugs I have tried to track down. Works if you are inside your home folder but not if you are outside of it.

@thaJeztah
Member

Actually, I am adding shared folder using command line:
VBoxManage sharedfolder add boot2docker-vm --name "Shared" --hostpath "folderInSystem"
and mount it inside boot2docker.

ping @ehazlett @tianon I'm not too familiar with the boot2docker sharing; given the above comment, the user has manually added an extra share, but docker doesn't seem to pick that up; any ideas?

@tianon
Member
tianon commented Aug 31, 2015

You have to mount additional shares manually (or via bootlocal.sh/bootsync.sh), or they will not be available inside the VM.

@MJ-Lee
MJ-Lee commented Sep 1, 2015

@tianon @thaJeztah
Hello,
Yes, I already mounted it inside boot2docker vm(source code as following):
sudo mkdir -p /shared
sudo mount -t vboxsf -o rw,uid=1000,gid=1000 Shared /shared
and I can see the contents inside boot2docker vm.
however when I try to docker build -f /tmp/xxx (and I use /tmp folder inside boot2docker vm where to create Dockerfile)

lrwxrwxrwx 1 root root 13 Sep 1 08:55 tmp -> /mnt/sda1/tmp/

I got the issue:
unable to prepare context: The Dockerfile (/xxx) must be within the build context (/xxx)

It's not a problem of shared system, I guess it's the docker1.8 cannot read the /tmp path for building with a file specified.

While docker 1.7 has no such problem

@902Labs
902Labs commented Sep 11, 2015

I am running an Ubuntu VM on OSX with VMWare Fusion.

My code directory is mounted and the following works just fine.

sudo docker build -f Dockerfile -t "$PKG" .

If I su into root and go into the same directory running the exact same command I get the context error referenced in above posts.

@jmanning2k

docker 1.8.1 on OSX via docker-machine

When building using boot2docker or docker-machine in a symlinked folder (/tmp/repo symlinked to /User/username/src/repo):

$ docker build -t XXXpwd``

works just fine, as the symlink for pwd seems to get resolved locally, or at least before going into the VM.

However:

$ docker build -t XXX --file Dockerfilepwd$ docker build -t XXX --file pwd/Dockerfile `pwd```

both fail, while using absolute paths (resolving symlinks) for both:

$ docker build -t XXX --filepwd -P/Dockerfilepwd -P``

is successful. This is definitely an issue of resolving symlinks for one path, while comparing with unresolved symlinks for another.

The error seen is:
unable to prepare context: The Dockerfile (/tmp/repo/Dockerfile) must be within the build context (/tmp/repo)

Please reopen - this is not the same as the linked issue.

@rncry
rncry commented Sep 25, 2015

Please reopen.. I'm having the same issue. I'm not using symlinks. I've tried writing out the whole path of both the file and the current context in various combinations, all fail.

Centos 7
docker -v
Docker version 1.8.2, build 0a8c2e3

@rrnewton

Just to confirm, @mingfang's docker-test reproducer does reproduce the problem for me on my mac:

$ docker --version
Docker version 1.8.1, build d12ea79
$ cd /tmp
$ git clone git@github.com:mingfang/docker-test.git
$ cd docker-test
$ docker build -f docker/Dockerfile -t test .
unable to prepare context: The Dockerfile (/tmp/docker-test/docker/Dockerfile) must be within the build context (.)

I notice that version is now out of date. I'll try with the 1.8.2a release of Docker Toolbox. The same recipe above now works fine for me on Linux, ubuntu 14.04 with Docker version 1.8.2, build 0a8c2e3.

@jmanning2k

I've opened issue #16339 specifically targeting this issue, since this is already closed. Please add your comments there.

@thaJeztah
Member

@irbik not sure I understand; INSTRUCTION is not a Dockerfile command; https://docs.docker.com/engine/reference/builder/

@duglin
Contributor
duglin commented Dec 18, 2015

@irbik I'm confused. This issue is about using "-f" but you're not using it.
Also, your Dockerfile works just fine for me.
What error are you seeing?

@irbik
irbik commented Dec 18, 2015

Sorry I can delete the wrong post. I got confused

@karlosmid

On windows 7, and using docker-quickstart-terminal, followin cmd worked for me:

docker build -t centos-node .

@thaJeztah
Member

@karlosmid you're also not using the -f option so that's not related; please don't comment on closed issues, or at least make sure your issue is related to the issue.

@karlosmid

@thaJeztah I posted workaround for not using -f option in the first place.

@singhniraj

I was having same issue with dockers on window 7. The solution is to provide the the directory where docker will look for docker file.

"docker build -f path/to/Dockerfile -t test ." This will look for docker file in the dir where the docker client exists. Instead you should provide

"docker build -f path/to/Dockerfile -t test <<basedir of your dockerfile e.x d:/project/docker>>"

@insertinterestingnamehere

I was having this issue as well when working with Windows Server containers. In my case, the dockerfile had inadvertently been created as Dockerfile.txt rather than just Dockerfile. The main issue wasn't symlinks. It was a bad filename and an unhelpful error message.

@hoshn
hoshn commented Apr 6, 2016
@Rahul91
Rahul91 commented Apr 16, 2016

I was having the same issue, until the got the correct meaning of context. The relationship between Dockerfile and context, in programming terms can be explained with the concept of scope i.e. Dockerfile should be in the scope(just for our understanding) of context or as the error mentions context must contain Dockerfile.

You can have your Dockerfile anywhere in your home directory and you can use home as context

/home/user/$ docker build -f somedir/somedir/somedir/somedir/Dockerfile .

this will work because (.) i.e home directory contains Dockerfile

But if its reversed i.e.

/home/user/$ docker build -f ~/Dockerfile somedir/somedir/somedir/somedir/

It will throw the error and rightly so, as Dockerfile is not in context.

@elycruz
elycruz commented Jun 3, 2016

Ha! I had DockerFile instead of Dockerfile lol

@orangebook

docker build [options] PATH | URL 使用Dockerfile构建镜像
that PATH OR URL just like build Context,So just you alerady write --file "pwd"/path/dockerfile
but you don't choose buildcontext ,that also make it error

@jamesone

Make sure your naming is correct! I had Dockefile :P This was also generated by IntelliJ

@tjtanvir666

make sure the file is not Dockerfile.txt it should be Dockerfile wihtout any extension

@zored
zored commented Jan 18, 2017

Why can't I specify Docker file from one location and context from another?

@thaJeztah
Member

@zored currently, the Dockerfile is sent to the daemon as part of the build-context, and the --file option only specifies where the daemon / builder can find the Dockerfile inside the build-context (basically, the build-context is a .tar of the directory you specify as context).

This case came up recently in a discussion, and I (personally) don't see a real issue with the Dockerfile being pulled from "anywhere", and sent together with the build context (where it's put at the "root" of the build context during build), so e.g.;

docker build -t myapp -f /shared/dockerfiles/Dockerfile1 /projects/projecta/

In the above;

  • /projects/projecta/ is the build context to build from
  • /shared/dockerfiles/Dockerfile1 is the Dockerfile to use for building

The docker client would either send the Dockerfile separately, or include it in the build-context (.tar), and during build, the Dockerfile is put at the root of the build context.

There may be technical issues with implementing that, but I would not be against allowing that.

Actually: I just recalled where it came up as well; #27393

@AgentCoop

I would like to keep all my docker config files in one place rather than being scattered all over the project directory tree. They definitely should change that behaviour.

@thaJeztah
Member

@AgentCoop perhaps you can open an issue / proposal / feature request for that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment