Thanks for the fast response :) Any reasons why the installer cannot run that addVolume command for me then?

The installer already handles this for cases where filevault is not enabled, the combination of filevault and an unencrypted store is nonsensical and shouldn't be automated by the installer.

But why does it fail in certain cases then (like the issue I linked above, or the 2017 MBP I tested it with)?

I don't understand the question, as stated above and in the manual if filevault is enabled for the boot volume and no hardware encryption is available some kind of encryption also needs to be setup for the store volume. Just doing it anyway and relying on the user noticing that their installation is in a bad state, while convenient, isn't a good default. Anybody that has enabled filevault on their machine should also care about this.

Got your point now :-)

I guess then we should point the user into the right direction (e.g. explain which steps need to be done). Right now the linked documentation doesn't really explain what to do next. Thus the user is stuck.

Alternative: Can't we ask the user for a password during installation and then set it up automatically? Like

read -sp "Password for Nix Volume: " pass
sudo diskutil apfs addVolume "$disk" APFS 'Nix Store' -mountpoint /nix -passphrase "$pass"

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/installation-on-macos-catalina/7804/4

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/installing-nix-on-macos-catalina-with-encrypted-boot-volume/7833/2

I think we have to do better, most of macos users expect things to just work and that's one of the main reasons they have a mac opposed to a linux machine. The reason we have to care is because that's the experience you get just when you install Nix, before doing anything useful.

Currently it's not clear why they are getting the error and what they should really do.

I think changing nix store location or symlinks shouldn't even be mentioned as both have significant downsides.

It's not clear to me why we can't offer more automation with encrypting the volume and how would the user decrypt it then?

Currently it's not clear why they are getting the error and what they should really do.

I can see the security perspective, but to me adding --darwin-use-unencrypted-nix-store-volume already conveys "I understand that this is insecure, but I want you to do it anyway".

I'm not sure this PR is the right place for the whole discussion spool out, but I'm not sure where it should move and we're here now so I'll do a bit of a braindump with the intent of porting it elsewhere (with corrections if anyone sees something I've got wrong or missed) as needed :)

How we got where we are

@LnL7 put forward the PR to fix the installer that endured months of hammering and multiple stalls before reaching completion. On the technical side, I recall it breaking down around a few points:

1. It's probably not acceptable to users (and we have direct feedback that some orgs have policies against it) to automatically create an unencrypted volume if the boot volume was already encrypted.
2. We haven't identified any way to re-use the boot volume's encryption for another volume, so encrypting it entails a new credential. I'm not sure we know if it's OK (for all users) if we just generate a "random" credential for this.
3. We had two FileVault flows figured out at the time of the PR, but both have a problem:
   • Encrypting the device and adding the password to keychain comes with a chance things will break because the mount may not be decrypted before restored apps and launchd services need something on the volume. We weren't comfortable defaulting anyone into this sort of problem.
   • Encrypting the volume and using some sort of login script/hook mechanism (I don't remember the precise name of this off the top of my head) solves this problem, but entails leaving the password in plaintext in a file. The mechanism itself also appears to be deprecated (but has been for a long time...), so we don't know if it'll be stable anyways.

The PR had stalled out around documentation issues. At the time, the installer was punting to documentation. LnL had asked for help documenting the various options multiple times, but hadn't gotten any. Over time, threads on this issue were devolving into a Lord-of-the-Flies situation. After one of these dust-ups I jumped in (despite feeling out of my depth dealing with the installer) to help document the options and try to advocate for solving any cases we could automatically solve. We:

1. Bit off the cases we felt vaguely comfortable handling without feeling obliged to encrypt the store, and made a painfully explicit/verbose flag to ensure no one can claim they didn't give us consent not to encrypt the store.
2. Punted to docs on any cases we haven't solved.
3. In part because we know the core issue still needs work and in part to try and head off the case where someone shows up every N days to ask why we can't just do X, we documented the plausible solutions.

Outside of the scope of closing out the PR, there was a parallel effort to add a walk-through of the recommended encryption workflow that fell through.

I think the current state sucks, but it's a lot better than having no working installer, sending everyone out on their own to invent their own bespoke solutions, and having various threads and blog posts devolving towards abuse.

Where it seems like it should go from here

Someone else independently figured out an encryption workflow that, as far as we know, works. If it does indeed skirt the decrypt race condition, the key appears to be putting the credential in the system keychain. You can find this discussed on IRC, and implemented (in ruby) in this gist.

Edit: I'll start adding additional substantive discussions as I become aware of them:

• nixos-dev on July 15 2020

There's still at least one question here: is it acceptable to just generate a password and use it to encrypt the store for everyone with FileVault enabled on their boot volume.

If the answer is yes, it needs someone to dive in on the implementation and confirm it delivers. (It may be gratifying to be the hero here, but I'm juggling multiple projects that are all falling behind lately and I'm in "no" mode for a while.)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-on-macos-catalina-risks-with-unencrypted-nix-store-possibilities-for-encrypted-nix-store/8134/4

The work in #4289 will make this moot if/when it lands. It'll encrypt the volume if FV is enabled, and remove the flag/message at issue, here.

@abathur thanks a lot for working on this :)

Will close this issue as this looks to be resolved very soon.