Custom store location

Hi all - I’m new here, trying to set things up on an Arch linux machine with only 5GB left in my root partition. I have 150GB over on a separate partition and I really want to use that for my store location.

According to this thread (Is Nix right for our use? Custom path and custom directory - #4 by FRidh) you can just set NIX_STORE_DIR as a variable.

I tried this by running:

export NIX_STORE_DIR=/path/to/new/store

but I still get this error like it’s looking in the old default location that I don’t want to use:

error: path 'nix/store/thing' is not in the Nix store

Can someone please advise me on what is the best way simply to move the store location to another partition?
Thanks for your help.

1 Like

I wouldn’t recommend moving store from /nix/store as this would prevent cache usage and I think some packages incorrectly assume /nix/store is the store path.

This can be done, but considering you want to move /nix/store to another partition rather than say need multiple stores for whatever reason, you may consider mounting location on your another partition to nix store.

mount --bind /path/to/nix /nix

It’s also possible to use btrfs subvolumes or zfs datasets if you use those particular file systems.


This is pretty rare, and should probably be reported and fix if anyone starts to care…

But for binary cache use and general tricky configuration reasons, alternative store location is definitely possible but not trivial, bind mounts are indeed orders of magnitude easier if the only issue is using the space from a different device.

1 Like

Thank you both -

I am using ext4 (unfortunately -?) so I cannot use subvolumes or datasets, but the mount did seem to work. I just brought in about 6gb of content into my other partition and am now in nix-shell so looks good so far. Thank you! :+1:

I like Ext4 for /home/ but for /nix/store/ I use BtrFS. There is basically just one catch to remember about: Nix uses a lot of symlinks, so in principle it is sometimes possible (on Ext4, many other filesystems allocate inodes dynamically) to run out of inodes (df -i) before running out of actual space. Of course the error code is the same, ENOSPC, so some people end up debugging the problem for some time before finding out what the problem is…


that would definitely have cost me hours if I didn’t know about it. Thanks for the tip.