cc @adnelson @Profpatsch

I wrote a simple test to check whether dockerTools image generation works.

@GrahamcOfBorg test docker-tools

Success on aarch64-linux (full log)

Success on x86_64-linux (full log)

docker: exit status 1
syncing
docker: running command: sync
docker: exit status 0
test script finished in 15.52s
cleaning up
killing docker (pid 593)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/tmp/nix-build-vm-test-run-docker-tools.drv-0/vde1.ctl': Directory not empty
/nix/store/majn1mnidiwjpj3fsg6dxcq1hka3bp77-vm-test-run-docker-tools

LGTM

Do you think we can backport this into 17.09?

Yeah, why not. I’m not sure how backports work tbh, I think the easiest is if you recreate the PR against the stable branch.

I just confirmed that this caused LnL7/nix-docker#14 (comment) and the chmod workaround I used doesn't work with older versions of aufs.

Reverting these changes works everywhere LnL7/nix-docker@aebee91.

@LnL7 It’s not clear to me what broke exactly and how to act on it.

Because /nix is not in the layer it shows up as drw------- 4 root root 4 Apr 12 22:36 nix. Users in the container can't list/read the store causing errors like binaries failing to find ld-linux-x86-64.so.2.

Ah, hm. @nlewo did you originally push this because you wanted to run nix inside the docker container?
Because in that case, why not make /nix into a volume for such use-cases?

Personally I’d say /nix should be rather static inside images.

@LnL7 If you add a (failing) VM test for your use-case, we can use it for regression testing in the future.

I did this because you must not read /nix/store at image creation. Basically, the /nix/store is not immutable and tar fails if /nix/store is modified during taring. It is more detailed in #34137.

We are also facing the user permission problem that is addressed in #38837.

I also think we should add a test regarding user permissions.

I posted here because I still don't really understand what this fixes, but since you approved the other pr I will assume it won't reintroduce this problem.