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

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

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

Comments

Projects
None yet
@wzheng2310

wzheng2310 commented Jul 1, 2015

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 comment has been minimized.

Show comment
Hide comment
@wzheng2310

wzheng2310 Jul 1, 2015

This is a duplicate of issue #11289.

wzheng2310 commented Jul 1, 2015

This is a duplicate of issue #11289.

@wzheng2310 wzheng2310 closed this Jul 1, 2015

@rrnewton

This comment has been minimized.

Show comment
Hide comment
@rrnewton

rrnewton Aug 14, 2015

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 .

rrnewton commented Aug 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 14, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@rrnewton

rrnewton Aug 14, 2015

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 commented Aug 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rrnewton

rrnewton Aug 15, 2015

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

rrnewton commented Aug 15, 2015

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

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 15, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@p16

p16 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

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 16, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 16, 2015

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)

Member

thaJeztah commented Aug 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 16, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 16, 2015

Member

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

Member

thaJeztah commented Aug 16, 2015

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

@rrnewton

This comment has been minimized.

Show comment
Hide comment
@rrnewton

rrnewton Aug 16, 2015

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

rrnewton commented Aug 16, 2015

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

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 16, 2015

Contributor

@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.

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

This comment has been minimized.

Show comment
Hide comment
@ghudiczius

ghudiczius Aug 18, 2015

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

ghudiczius commented Aug 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mingfang

mingfang Aug 20, 2015

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

mingfang commented Aug 20, 2015

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

@wzheng2310

This comment has been minimized.

Show comment
Hide comment
@wzheng2310

wzheng2310 Aug 20, 2015

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.

wzheng2310 commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 20, 2015

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@mingfang

mingfang Aug 20, 2015

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).

mingfang commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghudiczius

ghudiczius Aug 20, 2015

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

ghudiczius commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 20, 2015

Contributor

@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.

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

This comment has been minimized.

Show comment
Hide comment
@ghudiczius

ghudiczius Aug 20, 2015

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

ghudiczius commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mingfang

mingfang Aug 24, 2015

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.

mingfang commented Aug 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Aug 24, 2015

Contributor

ping @tianon

Contributor

duglin commented Aug 24, 2015

ping @tianon

@MJ-Lee

This comment has been minimized.

Show comment
Hide comment
@MJ-Lee

MJ-Lee Aug 27, 2015

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

MJ-Lee commented Aug 27, 2015

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 27, 2015

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

Member

thaJeztah commented Aug 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@MJ-Lee

MJ-Lee 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.

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

This comment has been minimized.

Show comment
Hide comment
@michaeljs1990

michaeljs1990 Aug 31, 2015

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.

michaeljs1990 commented Aug 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 31, 2015

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?

Member

thaJeztah commented Aug 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Aug 31, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@MJ-Lee

MJ-Lee 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

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

This comment has been minimized.

Show comment
Hide comment
@902Labs

902Labs 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.

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

This comment has been minimized.

Show comment
Hide comment
@jmanning2k

jmanning2k Sep 11, 2015

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.

jmanning2k commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rncry

rncry 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

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

This comment has been minimized.

Show comment
Hide comment
@rrnewton

rrnewton Sep 25, 2015

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.

rrnewton commented Sep 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jmanning2k

jmanning2k Sep 25, 2015

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

jmanning2k commented Sep 25, 2015

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 18, 2015

Member

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

Member

thaJeztah commented Dec 18, 2015

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

@duglin

This comment has been minimized.

Show comment
Hide comment
@duglin

duglin Dec 18, 2015

Contributor

@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?

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

This comment has been minimized.

Show comment
Hide comment
@irbik

irbik Dec 18, 2015

Sorry I can delete the wrong post. I got confused

irbik commented Dec 18, 2015

Sorry I can delete the wrong post. I got confused

@karlosmid

This comment has been minimized.

Show comment
Hide comment
@karlosmid

karlosmid Feb 3, 2016

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

docker build -t centos-node .

karlosmid commented Feb 3, 2016

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

docker build -t centos-node .

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Feb 3, 2016

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.

Member

thaJeztah commented Feb 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@karlosmid

karlosmid Feb 3, 2016

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

karlosmid commented Feb 3, 2016

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

@singhniraj

This comment has been minimized.

Show comment
Hide comment
@singhniraj

singhniraj Feb 26, 2016

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>>"

singhniraj commented Feb 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@insertinterestingnamehere

insertinterestingnamehere Mar 22, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment

hoshn commented Apr 6, 2016

@Rahul91

This comment has been minimized.

Show comment
Hide comment
@Rahul91

Rahul91 Apr 16, 2016

I was having the same issue, until I 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.

Rahul91 commented Apr 16, 2016

I was having the same issue, until I 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

This comment has been minimized.

Show comment
Hide comment
@elycruz

elycruz Jun 3, 2016

Ha! I had DockerFile instead of Dockerfile lol

elycruz commented Jun 3, 2016

Ha! I had DockerFile instead of Dockerfile lol

@orangebook

This comment has been minimized.

Show comment
Hide comment
@orangebook

orangebook Aug 15, 2016

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

orangebook commented Aug 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jamesone

jamesone Aug 31, 2016

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

jamesone commented Aug 31, 2016

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

@tjtanvir666

This comment has been minimized.

Show comment
Hide comment
@tjtanvir666

tjtanvir666 Jan 13, 2017

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

tjtanvir666 commented Jan 13, 2017

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

@zored

This comment has been minimized.

Show comment
Hide comment
@zored

zored Jan 18, 2017

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

zored commented Jan 18, 2017

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 18, 2017

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

Member

thaJeztah commented Jan 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@AgentCoop

AgentCoop Jan 26, 2017

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.

AgentCoop commented Jan 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 26, 2017

Member

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

Member

thaJeztah commented Jan 26, 2017

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

@liuxuzxx

This comment has been minimized.

Show comment
Hide comment
@liuxuzxx

liuxuzxx Sep 5, 2017

My docker version is 1.6.2, My error info is :The Dockerfile (Dockerfile) must be within the build context (./jdk-tomcat) . so how can i solve the problem?

liuxuzxx commented Sep 5, 2017

My docker version is 1.6.2, My error info is :The Dockerfile (Dockerfile) must be within the build context (./jdk-tomcat) . so how can i solve the problem?

@tmarshall

This comment has been minimized.

Show comment
Hide comment
@tmarshall

tmarshall Sep 30, 2017

I was running into the same issue, on OSX 10.12.4

$ docker --version
Docker version 17.06.1-ce, build 874a737

Problem happened because I am dynamically generating a Dockerfile, and placing it in a tmp dir. E.g. /var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile

Then:

DOCKERFILE_PATH="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile";
docker build -t "test" -f "$DOCKERFILE_PATH" .

^ this will fail, giving:

unable to prepare context: the Dockerfile (/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile) must be within the build context

Though, changing my build command to this works:

DOCKERFILE_DIR="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/";
DOCKERFILE_PATH="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile";
docker build -t "test" -f "$DOCKERFILE_PATH" "$DOCKERFILE_DIR"

Which is fine for me, since the build context doesn't really matter in my case, but prob will cause issues for others.

tmarshall commented Sep 30, 2017

I was running into the same issue, on OSX 10.12.4

$ docker --version
Docker version 17.06.1-ce, build 874a737

Problem happened because I am dynamically generating a Dockerfile, and placing it in a tmp dir. E.g. /var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile

Then:

DOCKERFILE_PATH="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile";
docker build -t "test" -f "$DOCKERFILE_PATH" .

^ this will fail, giving:

unable to prepare context: the Dockerfile (/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile) must be within the build context

Though, changing my build command to this works:

DOCKERFILE_DIR="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/";
DOCKERFILE_PATH="/var/folders/r2/b4thjjrd0js3fyp091ydqy0w0000gn/T/tmp.N20VpqFA/base.Dockerfile";
docker build -t "test" -f "$DOCKERFILE_PATH" "$DOCKERFILE_DIR"

Which is fine for me, since the build context doesn't really matter in my case, but prob will cause issues for others.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Sep 30, 2017

Member

If you're dynamically generating the Dockerfile, there's no need to save it to a file first, just pipe it in through stdin

Member

thaJeztah commented Sep 30, 2017

If you're dynamically generating the Dockerfile, there's no need to save it to a file first, just pipe it in through stdin

@tmarshall

This comment has been minimized.

Show comment
Hide comment
@tmarshall

tmarshall commented Sep 30, 2017

@thaJeztah yeah good point

@redbaron

This comment has been minimized.

Show comment
Hide comment
@redbaron

redbaron Dec 27, 2017

Contributor

@thaJeztah ,

@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).

It contradicts documentation, which says (https://docs.docker.com/engine/reference/builder/#usage):

Traditionally, the Dockerfile is called Dockerfile and located in the root of the context. You use the -f flag with docker build to point to a Dockerfile anywhere in your file system.

$ docker build -f /path/to/a/Dockerfile .
Contributor

redbaron commented Dec 27, 2017

@thaJeztah ,

@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).

It contradicts documentation, which says (https://docs.docker.com/engine/reference/builder/#usage):

Traditionally, the Dockerfile is called Dockerfile and located in the root of the context. You use the -f flag with docker build to point to a Dockerfile anywhere in your file system.

$ docker build -f /path/to/a/Dockerfile .
@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 27, 2017

Member

@redbaron good catch; looks like that's not properly documented; would you be interested in opening a pull request to fix that? the file used to create that part of the documentation can be found in the docker/cli repository: https://github.com/docker/cli/blob/master/docs/reference/builder.md

Member

thaJeztah commented Dec 27, 2017

@redbaron good catch; looks like that's not properly documented; would you be interested in opening a pull request to fix that? the file used to create that part of the documentation can be found in the docker/cli repository: https://github.com/docker/cli/blob/master/docs/reference/builder.md

@redbaron

This comment has been minimized.

Show comment
Hide comment
@redbaron

redbaron Dec 27, 2017

Contributor

@thaJeztah , I'd think that if product behavior diverges from documentation, it is a bug in product requiring fixing :)

Contributor

redbaron commented Dec 27, 2017

@thaJeztah , I'd think that if product behavior diverges from documentation, it is a bug in product requiring fixing :)

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 28, 2017

Member

See my earlier comment #14339 (comment) if you'd like to implement the code changes to match the incorrect documentation, that's fine with me as well 😇

Member

thaJeztah commented Dec 28, 2017

See my earlier comment #14339 (comment) if you'd like to implement the code changes to match the incorrect documentation, that's fine with me as well 😇

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