`nix optimise-store`: skipping suspicious writable file

1

I recently learned about nix optimise-store.

It shows a lot of lines similar to this:

skipping suspicious writable file '/nix/store/zrazw25gy012ip7vcqddw6lcc393qvcg-xz-5.2.4-bin/bin/xzmore'

wc says output overall is 1246 lines, though this might include a summary or other errors/warnings I have not yet seen because of the flood.

Is there anything I can do to fix the permissions on those pathes?

I hoped nix docotr would do, but it just gives an unhelpful output ("Store uri: daemon"), and I don’t even know if it repaired or only checked things or did nothing, or…

2

I’m also curious to the question about this particular warning. For the nix doctor output, BTW, once we do the next nix release the output will get much better and tell you what it’s actually checking, which check(s) pass, and so on.

https://github.com/NixOS/nix/pull/3102

1 Like
3

This problem does not occur on a nixOS installation as it seems.

It only happens on my 3 instances which are nix enhenced Arch Linuxes.

The only “pure” nixOS laptop I have just went through a nix store with ~20k pathes without a single “suspicious writable file” reported.

Is a single sudo chmod a-w -R /nix/store/ enough to fix the problem? Will it create new problems?

4

I ran into this issue myself, and couldn’t find an easy way to fix. In then end I came up with a janky shell command that does the trick. You can find it here: https://github.com/malob/nixpkgs/blob/802d127379370312b5a5bfadfeebb777f42b6bdd/overlays/common-env.nix#L22

5

Nice, I think I will adapt that one.

Though shouldn’t it be self.pkgs.parallel? I watched a talk recently (which was from '17) where they said, "super for functions, self for packages".

6

Though shouldn’t it be self.pkgs.parallel ? I watched a talk recently (which was from '17) where they said, " super for functions, self for packages".

No sure. My current convention has been to use self when I need to refer to something I’ve added in an overlay, and super otherwise. That said, even though I use overlays quite a bit in my user config, I still feel confused about best practices, so I could be doing a bunch of stuff “wrong”.

If it’s easy to find, I’d appreciate link to that talk.

7

I think it was this one:

1 Like
8

I’m honestly not even sure why it’s super for functions; certainly any package pulled in via super.callPackage will end up pulling its own functions from self (because super.callPackage still uses self to resolve the package environment). But it’s certainly true that dependencies (e.g. packages) must be self or else overlays can’t replace packages.