Change:
{ } '' mkdir -p $out <del> cp -prd ${nixpkgs} $out/nixos </del> <ins> cp -prd ${nixpkgs.outPath} $out/nixos </ins> chmod -R u+w $out/nixos if [ ! -e $out/nixos/nixpkgs ]; then ln -s . $out/nixos/nixpkgs

Discussion:
In the wiki page we recommend importing to get an initial copy of the channels. However, since yesterday (I only noticed it yesterday) when this import is , I have an error preventing me from building my derivation (It works without the import). I think I've identified the line causing the error. Follow the guide, and make sure you have the import. I had managed to reproduce the issue on a VPS with the latest version of the channels.
Can you look at the NIX_PATH and verify none of paths are broken symlinks?
I'm hitting this too on a freshly booted VBox OVA of nixos-unstable when I try my first nixos-rebuild. Nothing special in my config, just the default of the demo VM + some keymap/locale/xserver resolution settings. All paths in my NIX_PATH points to an existing directory.
We might be able to avoid this with: But it makes me wonder if the Git repo has a dangling symlink somewhere? Hopefully we can get some tests to avoid this.
Could you try: or ?
Sure. Nothing found:
I copied and other imported .nix under my /etc/nixos and commented the --rebuilds successfully Uncommenting it and replacing the chmod with --rebuild failing again with the error message But that chmod has been here for years so it's not the source of this recent issue. The ownership of the problematic file is probably not right (should be ):
Maybe tools changed? Recent coreutils changed some behavior re:links, but just a possibility. Here's the NEWS file in case it helps: . Dunno where that chmod comes from, maybe BusyBox...
It's:
May be related to changes wrt channels and stuff? Just a guess though.
It may be relevant yes. coreutils 8.30 has been merged two months ago so if it was just a regression in cp/chmod it would have bite anyone on unstable sooner, I guess?
I managed to rollback and use coreutils 8.29 and still have the "cannot operate on dangling symlink" error.
By modifying the commands launched for the and testing two or three things, I realized that the (or ) could not be visited by the builder, and when I used on it the script would stop (with no error).

Then, when I look after the build (outside the builder) the symlink points me to the right place. I suppose that the error comes from the fact that the symlink does not yet point to anything during the build.
It touches the same files but none of my changes got in
FWIW is not sufficient to suppress the error, for some reason. Commenting out the line entirely allows the build to proceed for me...
Can someone try out and confirm this fixes their issue? Thanks
I'll be able to test in a week after some holidays, if no one else test it before
Always the same issue when using your changes.
I still have the issue with your merged commit. Should we reopen the issue ?
I've been seeing this issue as well and bisected it down to changes in , and indeed reverting that commit fixes the issue for me. Here's a small example I used to bisect this: which was invoked with: from within my local checkout, where is a symlink pointing to said checkout. The example does work as expected if I change: to It also works fine when is pointed to a directory directly without any symlinks. Otherwise it seems just the symlink is available within the build environment and it can't be dereferenced at build time (assuming sandboxing is on..). Unfortunately I don't quite understand what the commit in question is doing exactly, what might be causing this difference in behaviour and whether that's expected or not. /cc who authored the changes
That commit makes NixOS import Nixpkgs via instead of indirectly via , which makes sense because suppose new impurities are to they will not affect NixOS. The reason why it fails becomes more visible when comparing the paths: Path is defined in as , which clearly does not resolve the symlink by itself. does seem to . , It seems that only the last path element gets resolved, which in the case of is the symlink, but in case of it isn't. do you think that this is a behavior that should change? If not, perhaps we should have a builtin to explicitly canonicalize paths, in this case the part of
so what would be the proper way to import a file from after ? E.g. is no longer working.
You should not have to change anything. This seems to be a Nix problem.

Nix will copy dangling symlinks into the store instead of following them, issue: Surprising canonicalization behavior in evaluation masked this problem before
Hi I am getting below error " chmod 777 "D:cygwin64binpython" chmod: cannot operate on dangling symlink 'D:cygwin64binpython' " Could you please let me know how can I clear this?
it looks like you are using Cygwin and not Nix. Nix (not "*nix", not UNIX) is an alternative package manager that is not available in the Cygwin package list. Unless you have consciously decided to use the Nix package manager (in which case I apologize for the lengthy answer), you should probably contact Cygwin people if this persists. That said, you'll have to replace the symlink or create the file that it points to. If you need help with the basics of UNIX commands, this is not the right place to ask; ask on instead.
Thanks for your feedback. Will check with cygwin people