Change:
# Execute commands via the root shell. $machine->succeed("nixos-container run $id1 -- uname") =~ /Linux/ or die; <ins> # Execute a nix command via the root shell. (regression test for #40355) $machine->succeed("nixos-container run $id1 -- nix-instantiate -E 'derivation { name = "empty"; builder = "false"; system = "false"; }'"); </ins> # Stop and start (regression test for #4989) $machine->succeed("nixos-container stop $id1"); $machine->succeed("nixos-container start $id1");

Discussion:
I upgraded an imperative container from 17.03 to 18.03 with nixos-unstable on the host: 18.09pre139319. (Jellyfish), and now I can no longer run any nix commands: I also tried creating a fresh container and it breaks in the same way. on the container fails with: error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system system: 0, multi-user?: no, error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system version: 0, error: opening lock file '/nix/var/nix/db/big-lock': Read-only file system on the host system: system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.0.2, channels(goibhniu): "nixos-18.03pre120540.", channels(root): "nixos-18.09pre139319.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
I can confirm this issue on a clean 18.03 install. To reproduce:
This issue sees related
That’s the error messages you get when you try using nix together with . I suspect inside the imperative containers there might be a different version running than outside?
This doesn't seem to be the issue. the container is running the same nix version, it seems: Interestingly enough, the command crashes already
Aha, I think I found the culprit is mounted read-only into the container. Whilst in 17.09 I think it would have been read-write. (How else would an imperative container modify the nix store otherwise?) However, I do not have a 17.09 install at hand on which I could try this.
In nix 1.12, this lock was never acquired. So it was not a problem that the was mounted However, acquiring the lock throws an , However, in Nix 2.0, the following patch was introduced: Previously, the function would return on , but now the exception is actually raised... So this seems to be an issue with not working with a readonly folder.

I'm not very familiar with the source code, and why not throwing on EROFS was not an issue in the past. But I have a feeling this is a bug and should be filed in that repository as well.
You can work around this for now by remounting /nix/var/nix/db as read/write within the container:
Oh great! Thanks. Perhaps we should just add that line in the container code.
Making the host nix database writable in the container is a very bad idea, eg.
So how should the container connect to the host's nix-daemon? Docs read like it's only possbile to connect over ssh, or could you expose it as a file-based socket too?
Yes. It's a unix domain socket, running nix commands as an unprivileged user also use this to communicate with the daemon. By default it's located at , but it's possible to customize with the --store flag or NIX_REMOTE environment variable if you want another path inside the container.
Is there anyone who knows how this stuff works, and thinks can help me get it fixed before ? Otherwise I'd suggest removing containers from the documentation for the release as they currently just do not work at all anymore. And bringing it back in the release cc
I'm afraid I don't know about the internals, but containers do work for me as long as I stick with e.g. instead of logging in and trying .
I've updated the docs to reflect this
Okay, after some digging, I have found out what is going wrong, and how we can fix it. The fact that this worked before seems to have been pure coincidence. Because we are user within the container namespace, the commands assume single-user mode, and try to modify the store directly. However, the inside the user namespace is different than the that owns . Hence we can't modify the store at al, and the command crashes. Instead, we should force to talk to the host nix daemon instead: The solution is to force the user to use the host daemon, which we can do as follows: When we are not the user in the container, nix commands already work as expected... We should add the environment variable to the command, and then everything should work as expected...
Nice catch!