Turn NIX_IGNORE_SYMLINK_STORE=1 into a nix.conf option

[jwiegley]

It would be nice to permanently enable this through the system configuration.

[matthewbauer]

Could we just allow symlinked stores everywhere? Not sure what the rationale for that warning is. On macOS at least, symlinks are used for things like this all the time (/tmp is symlinked to /private/tmp, /etc is symlinked to /private/etc).

[edolstra]

The reason is that builders could canonicalize a path (e.g. do realpath $dir) and end up storing the symlink target in derivation outputs. Which is bad if the output is shared with other machines via a binary cache.

[pseudometric]

Links created with synthetic.conf(5) are just regular symlinks and have this problem; if I do that for Nix, I get the expected build problem: hash mismatch in fixed-output derivation. OS X now has ”firmlinks” which don’t have this problem — but there appears to be no way for users to add more. The system comes with a fixed set of them, listed in /usr/share/firmlinks; annoyingly, that includes /sw for Fink, /opt and /usr/local, but not /nix. I tried booting to single-user mode and adding an entry for /nix to that file, but that did nothing; it appears to be just a conveniently accessible list of the firmlinks maintained by the system, initialized once at build time and not actually used for anything.

Perhaps making a synthetic directory /nix and mounting a new APFS filesystem there will work, though I haven’t found a way to mount somewhere outside /Volumes.

[pseudometric]

Found a way:

• Create new case-insensitive APFS volume with Disk Utility (click the plus-sign above "Volume" at upper left).
• Find the volume UUID: diskutil list / diskutil info.
• Add a line reading /nix to /etc/synthetic.conf; this will result in an empty /nix directory on reboot, to be the mount point.
• Reboot to single-user ("recovery") mode: hold down command-R while rebooting.
• (in recovery mode) If your root disk is encrypted with FileVault, use Disk Utility to mount it; you'll need a key, which I believe can be the login password of any account authorized mount FileVault disks.
• Start Terminal in the Utilities menu.
• Create an fstab file on your root disk, which is not currently mounted as root; so e.g., /Volumes/Macintosh HD/etc/fstab. Contents:

UUID=1AAA96CE-6208-43B3-81FF-E80850920E5A       /nix    apfs    rw,auto,nobrowse

(substituting your UUID).

[pseudometric]

Oddly, I still get the following error. Perhaps there's just something wrong with this package, since using a mount seems as if it ought to remove the potential problem. I did successfully build a different package — but that doesn't actually prove anything. Maybe it's something to do with APFS? It is case-insensitive/case-preserving, which I suppose might also screw up a hashing scheme… I think there is a case-sensitive variant available, or at least there used to be. I'll try that.

trying https://salsa.debian.org/ssh-team/openssh/raw/e50a98bda787a3b9f53ed67bdccbbac0bde1f9ae/debian/patches/gssapi.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  125k  100  125k    0     0   216k      0 --:--:-- --:--:-- --:--:--  216k
hash mismatch in fixed-output derivation '/nix/store/ibfglnnkfpg9wn0cpkjbnkyqa1jxyblc-openssh-gssapi.patch':
  wanted: sha256:14j9cabb3gkhkjc641zbiv29mbvsmgsvis3fbj8ywsd21zc7m2hv
  got:    sha256:0zfxx46a5lpjp317z354yyswa2wvmb1pp5p0nxsbhsrzw94jvxsj
cannot build derivation '/nix/store/481rnfaca5nr77lnqd66frvhyc1xkm1g-openssh-8.1p1.drv': 1 dependencies couldn't be built
error: build of '/nix/store/481rnfaca5nr77lnqd66frvhyc1xkm1g-openssh-8.1p1.drv' failed

[pseudometric]

I changed it to a case-insensitive filesystem (which is probably best anyway; I updated the instructions above) — but that did not fix the problem with this particular package. So although this seems as if it should be a perfectly good solution, I still don’t know whether there’s some systemic problem, or just a problem with that package.

[pseudometric]

The failure was in fact a problem with that particular package, not related to the setup here.

[nixos-discourse]

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

https://discourse.nixos.org/t/allowing-nix-store-to-be-a-symlink-in-order-to-allow-a-daemon-less-multi-user-installation/39865/1