Deploy failed with error: COPY failed: no such file or directory

This might be more of a docker issue, tbh, however I haven’t been able to found anything useful so I’ll ask here regardless.

I’m trying to build and deploy an app, and it builds fine and alright, but then the deploy fails.
Project structure:


The content of docker-compose.yml:

    privileged: true
    build: ./app
    restart: always
    network_mode: 'host'

    restart: always
    build: ./flask
    network_mode: 'host'
      - '80:80'

And the content of the failing Dockerfile:

FROM balenalib/raspberrypi3-debian-python:3-buster-build


WORKDIR /usr/src/app

RUN apt-get update && \
    apt-get install -yq \

COPY src ./

COPY ./configs/supervisor_confd/* /etc/supervisor/conf.d/
COPY ./configs/owfs.conf /etc

CMD ["bash", ""]

After a successful build, the following deploy fails with:

[Error]   Deploy failed
Error: COPY failed: stat /var/lib/docker/tmp/docker-builder124511649/src: no such file or directory
    at Stream.<anonymous> (C:\snapshot\resin-cli\node_modules\resin-docker-build\build\builder.js:178:23)
    at (C:\snapshot\resin-cli\node_modules\through\index.js:26:11)
    at Stream.ondata (internal/streams/legacy.js:16:26)
    at emitOne (events.js:96:13)
    at Stream.emit (events.js:188:7)
    at drain (C:\snapshot\resin-cli\node_modules\through\index.js:36:16)
    at (C:\snapshot\resin-cli\node_modules\through\index.js:45:5)
    at Parser.exports.parse.parser.onToken (C:\snapshot\resin-cli\node_modules\JSONStream\index.js:132:18)
    at Parser.proto.write (C:\snapshot\resin-cli\node_modules\jsonparse\jsonparse.js:135:34)
    at Stream.<anonymous> (C:\snapshot\resin-cli\node_modules\JSONStream\index.js:23:12)
    at (C:\snapshot\resin-cli\node_modules\through\index.js:26:11)
    at IncomingMessage.ondata (_stream_readable.js:555:20)
    at emitOne (events.js:96:13)
    at IncomingMessage.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at IncomingMessage.Readable.push (_stream_readable.js:134:10)
    at HTTPParser.parserOnBody (_http_common.js:123:22)
    at Socket.socketOnData (_http_client.js:363:20)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:547:20)

The command with which I run the proces is:

DEBUG=1 balena deploy testApp2 --logs --source . --emulated --build --docker=//./pipe/docker_engine

It appears that the COPY fails when trying to execute COPY src ./. This seems like an issue with how paths are evaluated when docker-compose is run or something, though I haven’t been able to find a solution.

Kind regards

Hey @fruloops, Im not 100% sure, but I think if you are using Windows, its likely you are hitting this CLI bug . These two PRs are working towards fixing it, but Im not sure its gonna fully fix things yet.

@pdcastro has been working on that, so he might be able to add some more info on the bug and the coming fixes.

@fruloops, there is indeed a good chance that the issue you are reporting is the same CLI issue linked by @shaunmulligan. What happens is that the CLI creates a tar stream which should have only forward slashes as path separator, but under Windows in some cases back slashes are being used instead. The Dockerfile COPY instruction copies from that tar stream, and src may not be found because it was not properly added to the stream. There are few github repos that are affected and used by the CLI and the cloud builders; beside the two mentioned by Shaun, this other one as well:

They are under review and testing, and I hope that by the end of next week they will be deployed to the production environment (cloud builders) and released under a new CLI version.

@pdcastro @shaunmulligan Thank you for the swift responses, I’ll poke around to see if I can work around this, but otherwise wait for the fixes to be released.

Same issue here, with a really simple example in Windows 10 Pro x64
I’m using git Bash as my term, and balena push as my command.

Will wait for fix.

@fruloops, @webtop, I expect that version 10.3.0 of the CLI fixed this issue (assuming it was indeed the same issue that I was able to reproduce and test against with Windows 10). Would you mind testing it to confirm? Thanks!