Saving of scratch volume image not possible: ImageError response from daemon: empty export - not implemented

[countzero]

Description

The docker save command will not save an image that contains only a FROM scratch and a VOLUME declaration. It fails with:

Error response from daemon: empty export - not implemented

Steps to reproduce the issue:

1. Create a Dockerfile

cat <<EOF > Dockerfile
FROM scratch
VOLUME /var/log
EOF

2. Create an image from that Dockerfile

docker build -t emptyscratchvolume .

3. Try to save that image with docker save into a .tar file

docker save -o emptyscratchvolume.tar emptyscratchvolume

Describe the results you received:

It fails with:

Error response from daemon: empty export - not implemented

Describe the results you expected:

The docker save command should produce a .tar file that will be compatible with docker load.

Additional information you deem important (e.g. issue happens only occasionally):

The docker save command will work as expected if the image contains at least one file, like the Dockerfile itself:

cat <<EOF > Dockerfile
FROM scratch
COPY Dockerfile .
VOLUME /var/log
EOF

Output of docker version:

Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built: Wed Mar 21 23:10:06 2018
 OS/Arch:       linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:08:35 2018
  OS/Arch:      linux/amd64
  Experimental: false

Output of docker info:

Containers: 7
 Running: 3
 Paused: 0
 Stopped: 4
Images: 197
Server Version: 18.03.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfd04396dc68220d1cecbe686a6cc3aa5ce3667c
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.0-6-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.8GiB
Name: c3-development
ID: 5KME:NHKR:SAQH:EVTU:M5Y6:DKML:NU45:7USQ:2PAP:2DAC:ZR5I:QM2K
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

[thaJeztah]

Error comes from here;

moby/image/tarexport/save.go

Line 297 in 8e610b2

return nil, fmt.Errorf("empty export - not implemented")

[thaJeztah]

/cc @tonistiigi perhaps you know if there's a specific reason this was not implemented

[tonistiigi]

I guess it was for the v1.0 transport format compatibility where every layer is mapped to an image config and therefore the concept of an image without layers doesn't really exist. With the containerd implementation #38043 v1.0 save support should go away and solve this.

[thaJeztah]

Thanks @tonistiigi - makes sense

@countzero wondering; is your example just an "example" or is that your actual use case? From your example, it looks like you're using "data containers" so that you can reference volumes. The concept of using "data containers" is really outdated, now that volume management commands are available; for example, to create a named volume for your logs;

docker volume create mylogvolume

That volume can then be attached to a container;

docker run -d --volume mylogvolume:/var/log nginx:alpine

Named volumes will also be automatically created on-the-fly if they don't exist, so running;

docker run -d --volume makemeavolume:/var/log nginx:alpine

Will create a volume named makemeavolume if it doesn't exist yet, and otherwise use the existing makemeavolume volume; after that, the container is created, and the volume is attached to the container.

[countzero]

@thaJeztah Your assumption is correct. I am currently refactoring "legacy" code that dates back to the time when Docker was not yet production ready (<v1.0). I am currently refactoring that code base and just replaced FROM busybox with FROM scratch, which lead to this bugreport.

Interestingly the Docker CLI and behaviour, that was present before ~4 years still works as expected. The infrastructure I am working on is controlled with simple Bash scripts. Those could nowadays be replaced by Docker compose or Docker swarm or Kubernetes or... you get the point ;D

[ghost]

I found this bug "in the wild" when I tried to use the Docker layer cache feature of the Bitbucket pipelines CI system.

One of my Dockerfiles contains FROM scratch, producing an image with an empty layer.
Because the CI system tries to export ALL the images after the build for caching, even the empty one, this bug gets triggered.

[mudler]

Are there any plans into fixing this? I've bumped into this myself, and I find this behavior a bit "incoherent" : you can create images FROM scratch with just metadata (e.g. by setting LABELS) so you can build empty images, but later on you can't export them.

In my use case I use "data containers" because I'm using docker images to carry data, and in some corner cases I have "empty" images to push and pull from. I can't use volumes, because such images aren't necessarily supposed to be run.