Varnish 7.1.0 cannot start with tmpfs-backed /var/lib/varnish

[spantaleev]

As originally reported here:

Starting the container like this fails:

$ docker run -it --rm -v $(pwd)/default.vcl:/etc/varnish/default.vcl:ro --tmpfs /var/lib/varnish:exec docker.io/varnish:7.1.0-alpine
Error: Cannot create working directory '/var/lib/varnish/varnishd': Permission denied
(-? gives usage)

Looks like running the 7.1 container image (which contains USER varnish) with --tmpfs /var/lib/varnish:exec (as recommended in the Docker Hub description) no longer works.

• [OK] docker run --rm --entrypoint=/bin/sh docker.io/varnish:7.1.0-alpine -c 'stat /var/lib/varnish' says 0750 / varnish / varnish -- the varnish user will be able to write to this

• [not OK] docker run --rm --entrypoint=/bin/sh --tmpfs /var/lib/varnish:exec docker.io/varnish:7.1.0-alpine -c 'stat /var/lib/varnish' says 0750 / root / root -- the varnish user will not be able to write to a root-owned directory with these permissions

• [not OK] docker run --rm --entrypoint=/bin/sh --mount type=tmpfs,destination=/var/lib/varnish,tmpfs-mode=1777 docker.io/varnish:7.1.0-alpine -c 'stat /var/lib/varnish' says 0750 / root / root -- same as the above - the varnish user will not be able to write to a root-owned directory with these permissions

• [OK] docker run --rm --entrypoint=/bin/sh --mount type=tmpfs,destination=/var/lib/another,tmpfs-mode=1777 docker.io/varnish:7.1.0-alpine -c 'stat /var/lib/another' says 1777 / root / root -- the varnish user will be able to write to this new root-owned /var/lib/another directory

The Debian-based image suffers from the same problem.

---

As a workaround, one might:

• remove the --tmpfs argument and have Varnish write to the container filesystem at /var/lib/varnish - not great
• start varnish with another tmpfs directory (e.g. --tmpfs /var/lib/varnish2:exec) by specifying another working directory: -n /var/lib/varnish2 - ugly, but tolerable
• try to work around the USER varnish thing by using --user (possibly --user=0:0) - not great

---

Applying the 2nd proposed workaround to the original command I reported trouble with, above:

docker run -it --rm -v $(pwd)/default.vcl:/etc/varnish/default.vcl:ro --tmpfs /var/lib/varnish2:exec docker.io/varnish:7.1.0-alpine -n /var/lib/varnish2

Could not delete 'vcl_boot.1648535199.387914/vgc.sym': No such file or directory
Error:
Message from VCC-compiler:
Backend host "www.nytimes.com:80": resolves to too many addresses.
Only one IPv4 and one IPv6 are allowed.
Please specify which exact address you want to use, we found all of these:
        151.101.1.164:80
        151.101.65.164:80
        151.101.129.164:80
        151.101.193.164:80
('/etc/varnish/default.vcl' Line 4 Pos 11)
  .host = "www.nytimes.com:80";
----------####################-

In backend specification starting at:
('/etc/varnish/default.vcl' Line 3 Pos 1)
backend default {
#######----------

Running VCC-compiler failed, exited with 2
VCL compilation failed

Varnish can start like that. It does choke on the VCL definition though (I've used the www.nytimes.com example from the Docker Hub description), but that's another problem.

[gquintard]

thanks for reopening here, the docs are indeed lagging a bit. The second issue comes from Varnish resolving the host at load-time and expecting a single IP address, this is addressed by https://github.com/nigoroll/libvmod-dynamic which is now included in the image since 7.1. I'll hopefully be able to cover the docs very soon.

Regarding the tmpfs issue, because the workdir changed a bit in 7.0 and because of the unprivileged approach in 7.1, the --tmpfs argument must now be /var/lib/varnish/varnishd:exec:

docker run --tmpfs /var/lib/varnish/varnishd:exec varnish:7.1

I've opened https://github.com/docker-library/docs/pull/2125 to at least sort that one out

[gquintard]

merged