`whoami: cannot find name for user ID` in `nix develop`

Help
1

Inside my flake I create a devShell devShells.default = pkgs.mkShell. For some reason, when I enter it, my username is missing:

[I have no name!@mypc ~]$ whoami
whoami: cannot find name for user ID 1045617922
[I have no name!@mypc ~]$ echo $PS1
[\u@\h \W]\$ 
[I have no name!@mypc ~]$ echo $USER
n.krasnov

I tried installing these packages, but they didn’t fix it:

buildInputs = [
  pkgs.bashInteractive
  pkgs.nss
  pkgs.nsss
  pkgs.shadow
  pkgs.nss_pam_ldapd
];
System info 
OS: Ubuntu 22.04.5 LTS x86_64
Kernel: Linux 6.8.0-59-generic
DE: GNOME 42.9
WM: Mutter (X11)

Related issue that went nowhere: whoami: cannot find name for user ID <user-id> · Issue #331 · target/lorri · GitHub.

[I have no name!@mypc ~]$ which whoami
/nix/store/9m68vvhnsq5cpkskphgw84ikl9m6wjwp-coreutils-9.5/bin/whoami
[I have no name!@mypc ~]$ whoami 
whoami: cannot find name for user ID 1046609540
[I have no name!@mypc ~]$ /bin/whoami 
myUserName
2

I did manage to make it work, but in no way is it a proper sollution:

$ nix profile install nixpkgs#sssd
$ LD_LIBRARY_PATH=~/.nix-profile/lib whoami
myUserName

Why doesn’t buildInputs = with pkgs; [ sssd ];work though? :frowning:

3

Fixed it! Yippee :tada:

shellHook = ''
  export LD_LIBRARY_PATH=${pkgs.sssd}/lib
'';
4

First off use packages not buildInputs (somehow the old way won’t die off…)

And if you’re setting LD_LIBRARY_PATH then something’s gone massively wrong. What OS and nixpkgs revision are you using? Are you using lorri? (I’d not heard the best things about it, I personally use direnv.)
And is your shell literally pkgs.mkShell with nothing else?

5

Here is my flake.nix

Summary 
{
  inputs = {
    nixpkgs.url = "nixpkgs/nixos-24.11";
    nixpkgs-unstable.url = "nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs =
    {
      nixpkgs,
      nixpkgs-unstable,
      flake-utils,
      ...
    }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        pkgs-unstable = nixpkgs-unstable.legacyPackages.${system};
        lib = nixpkgs.lib;
      in
      rec {
        devShells.default = pkgs.mkShell {
          packages = with pkgs; [
            bashInteractive
            sssd
          ];

          shellHook = ''
            #export LD_LIBRARY_PATH=${pkgs.sssd}/lib
          '';
        };
      }
    );
}

Yea, this I feel the same way. But why exactly is it true? Is it because Nix should make this path available automatically, without me doing it manually via LD_LIBRARY_PATH?

OS: Ubuntu 22.04.5 LTS x86_64
Kernel: Linux 6.8.0-59-generic
DE: GNOME 42.9
WM: Mutter (X11)

I don’t think revisions matter in my case. I’ve just replicated this without a lock file.

Nope. Only direnv. But I’ve just replicated this issue without it.

6

The problem here is, that other programs in the same environment might not find their own libraries in the correct versions anymore, as LD_LIBRARY_PATH is searched before the RPATH.

So if the LD-path contains libfoo.so version 3, while some app needs v2, then this app will break.

And even with a lib of the same versions, it could be beuilt with a different featureset, which makes an application to not work correctly.

7

But why doesn’t bash (or any other application like whoami) doesn’t see sssd libraries? Again, shouldn’t nix add them automatically?

I think I am missing something in my understanding of buildInputs/packages… From what I understand, declaring a package in one of these attribute sets (1) creates a nix store with specified package and (2) adds a symlinks to all files in this store. Which means when you enter a devShell, nix creates symlink /usr/lib/libfoo.s that points to /nix/store/hash-package/usr/lib/libfoo.so. I assume if this was true I wouldn’t need to set LD_LIBRARY_PATH manually. Is this correct?

Can someone please test my flake on non-NixOS system? Maybe this is only specific to my machine (why tho?).

Flake 
{
  inputs = {
    nixpkgs.url = "nixpkgs/nixos-24.11";
    nixpkgs-unstable.url = "nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs =
    {
      nixpkgs,
      nixpkgs-unstable,
      flake-utils,
      ...
    }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        pkgs-unstable = nixpkgs-unstable.legacyPackages.${system};
        lib = nixpkgs.lib;
      in
      rec {
        devShells.default = pkgs.mkShell {
          packages = with pkgs; [
            bashInteractive
            sssd
          ];

          shellHook = ''
            #export LD_LIBRARY_PATH=${pkgs.sssd}/lib
          '';
        };
      }
    );
}

Weirdly enough, even with LD_LIBRARY_PATH set I don’t have my username in the “first” bash shell (the one you see after running nix develop). Only after you run bash and open another sub-shell do you see your name in PS1. I didn’t notice this first because I had PS1 set.

Here is an screen recording of me showing this behavior — https://files.catbox.moe/1n4nmk.mp4

8

Doesn’t see them, or an incompatible version of them from the LD_LIBRARY_PATH is shadowing the actual relevant entry?

Again, whenever LD_LIBRARY_PATH appears in the environment, things might just work still, or they might break in ways that are hard to understand without knowing really the complete environment and what exactly is in that variable, and what lives in the folders listed in that variable, and what programs are ran under that environment.

9

As you can see from the video in my previous post, it’s adding the LD_LIBRARY_PATH variable that fixes the issue. Using sssd without setting the variable does nothing in terms of fixing this issue. Even though whoami binary actually comes from the /nix/store.

Could you please please test that on your machine? Do you have the same issue? Even though Nix is supposed to be hermetic, I feel like there might be something wrong with my Ubuntu 22 that causes that. I will try replicating this in a VM later.

Did not quite get the meaning of this but I do agree that setting LD_LIBRARY_PATH is a hack that should be avoided if possible.

10

Yea, I’ve just tested the flake on a Debian 12 VM and the issue is gone :') No sssd needed, no PS1 either.

How would I debug this? The reason I want to solve this is because the OS I’m running (Ubuntu 22) is provided to my by my company (it was preinstalled on the laptop and the BIOS is password-protected) — if the flake is broken for me, it might as well be broken for everyone else in my team/company.