Sops nix as a home-manager module does not create a symlink

[ircurry]

I have followed the README instructions, importing sops-nix in home manager via

home-manager.sharedModules = [inputs.sops-nix.homeManagerModules.sops]

(as I am using home-manager as a nixos module), set the sops default file, format and key via

sops = {
  defaultSopsFile = ../../secrets/secrets.yaml;
  defaultSopsFormat = "yaml";
  age.keyFile = "/home/myuser/.config/sops/age/keys.txt";
};

and attempted to decrypt it via

config = {
  sops.secrets.test = {
    path = "%r/test.txt"; # as well as through other paths such as "/home/recur/test.txt", "$XDG_RUNTIME_DIR/secrets/mySecret", and not setting it at all
  };
};

The expected behavior would be that the decrypted file would be put in the specified location. However, no symlink is made, though running

sudo cat /run/secrets/test

prints the contents of the secret.

I am unsure if this is a duplicate of #287 or not.

[w4tsn]

As I understand it the home-manager module creates the secrets under /run/user/<uid>/secrets, so the file should be /run/user/<uid>/secrets/test.txt after home-manager switch - but only after you've executed systemctl --user (re)start sops-nix.service

[piyoki]

As I understand it the home-manager module creates the secrets under /run/user/<uid>/secrets, so the file should be /run/user/<uid>/secrets/test.txt after home-manager switch - but only after you've executed systemctl --user (re)start sops-nix.service

Hi @w4tsn, thanks for your kind tips. It is indeed the case. After restarting the sops-nix.service, I can see the secrets there. Any idea how to automate the restart service step?

[piyoki]

Actually, it is highlighted in the readme.

[floating-cat]

I wasted some time investigating why sops-nix doesn't generate the secret files for me after using home-manager switch, then I noticed I needed to start systemctl start --user sops-nix once to generate them and found this issue.
I think sops-nix should do it automatically.

[Mic92]

I am currently not using the home-manager sops module but I am open to merge fixes.

[piyoki]

I wasted some time investigating why sops-nix doesn't generate the secret files for me after using home-manager switch, then I noticed I needed to start systemctl start --user sops-nix once to generate them and found this issue. I think sops-nix should do it automatically.

Exactly the same workaround I applied to my current config.

[ircurry]

It works for me as well, the file is where I specified it.

[ircurry]

I made a pull request, #485, documenting that you have to restart the service so that someone running into this issue can work around it. It doesn't fix the service not automatically reloading when a secret is changed but this is the best I can do since I don't have the knowledge required to actually fix that.

Should I change the name of the issue to more accurately reflect what the actually issue is or keep it the same for discoverability?

[madorian]

I don't understand why you are talking about "home-manager switch"; is that even used when home-manager is a module?

I also don't understand why I get

[root@pi:~]# systemctl --user restart sops-nix.service
Failed to restart sops-nix.service: Unit sops-nix.service not found.

I'm on Pi4 and I also can't get any file created;)

[ircurry]

@madorian are you using home-manager to configure the root user's home-directory? I've only gotten that when I have no secrets being deployed by home-manager in my current user's configuration.

[piyoki]

@madorian are you using home-manager to configure the root user's home-directory? I've only gotten that when I have no secrets being deployed by home-manager in my current user's configuration.

Same for me. By default if there is no secret, that unit service will not be created.

[madorian]

Not sure what you both mean.

I have this setting for root in home-manager

  home-manager.users.root = {
    home.stateVersion = "23.11";

  sops = {
    age.keyFile = "/home/b0ef/.config/sops/age/keys.txt";
    defaultSopsFile = ./secrets.yaml ;
    secrets.root_ssh_key_bytesized = {
        mode = "0600";
        path = "${config.home.homeDirectory}/.ssh/id_root_quasar-test";
    };
  };

[sedlund]

I have this setting for root in home-manager

systemctl --user is meant for user accounts not root. it will not work. I would also recommend against using home-manager on the root account. make a separate functional admin account if you need - anyway - this is way off topic...

[floating-cat]

I use the below in my home-manager config file to workaround this issue:

  home.activation.setupEtc = config.lib.dag.entryAfter [ "writeBoundary" ] ''
    run /usr/bin/systemctl start --user sops-nix
  '';

You may change /usr/bin/systemctl to a different path for your case.

[piyoki]

home.activation.setupEtc = config.lib.dag.entryAfter [ "writeBoundary" ] ''
run /usr/bin/systemctl start --user sops-nix
'';

Should use /run/current-system/sw/bin/systemctl instead of /user/bin/systemctl. I've tested this solution, and it indeed works. Thanks for coming up with this workaround.

[w4tsn]

I created a pull request based on the suggestion from @floating-cat with the addition of @yqlbu #491

I added some more description on the issue in the commit message together with two alternatives how this could be fixed inside the sops-nix home-manager module code.

[sedlund]

when using that work around and using deploy-rs with root as sshUser to deploy the user profile causes systemctl to fail:

Activating setupEtc
Failed to connect to bus: No medium found
⭐ ❌ [activate] [ERROR] There was an error de-activating after an error was encountered: Command for re-activating the last generation resulted in a bad exit code: Some(1)
🚀 ❌ [deploy] [ERROR] Activating over SSH resulted in a bad exit code: Some(1)
🚀 ℹ️  [deploy] [INFO] Revoking previous deploys
🚀 ❌ [deploy] [ERROR] Deployment failed, rolled back to previous generation

It works if sshUser is set to the profile user, but not ideal

[anotherhadi]

Those three lines:

  home.activation.setupEtc = config.lib.dag.entryAfter [ "writeBoundary" ] ''
      /run/current-system/sw/bin/systemctl start --user sops-nix
  '';

Cause an error when starting the home-manager-$user.service:

× home-manager-hadi.service - Home Manager environment for hadi
     Loaded: loaded (/etc/systemd/system/home-manager-hadi.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2024-03-17 02:35:18 CET; 48s ago
    Process: 1027 ExecStart=/nix/store/wyb6kadb8311qdv19kvrsqb7i6zqaw08-hm-setup-env /nix/store/z9jzqhmi9rrs361b71nfmjvcxvydb4ha-home-manager-generation (code=exited, status=1/FAILURE)
   Main PID: 1027 (code=exited, status=1/FAILURE)
         IP: 0B in, 0B out
        CPU: 683ms

mars 17 02:35:18 nixy hm-activate-hadi[1027]: No change so reusing latest profile generation 275
mars 17 02:35:18 nixy hm-activate-hadi[1027]: Creating home file links in /home/hadi
mars 17 02:35:18 nixy hm-activate-hadi[1027]: Activating onFilesChange
mars 17 02:35:18 nixy hm-activate-hadi[1027]: Activating reloadSystemd
mars 17 02:35:18 nixy hm-activate-hadi[1027]: User systemd daemon not running. Skipping reload.
mars 17 02:35:18 nixy hm-activate-hadi[1027]: Activating setupEtc
mars 17 02:35:18 nixy systemctl[1617]: Failed to connect to bus: No medium found
mars 17 02:35:18 nixy systemd[1]: home-manager-hadi.service: Main process exited, code=exited, status=1/FAILURE
mars 17 02:35:18 nixy systemd[1]: home-manager-hadi.service: Failed with result 'exit-code'.
mars 17 02:35:18 nixy systemd[1]: Failed to start Home Manager environment for hadi.

Does anyone have an idea why?

[sedlund]

 User systemd daemon not running. Skipping reload.

it looks like the user is not logged in (interactively) so the user systemd is not running, thus there's no daemon to tell to start the service

[anotherhadi]

 User systemd daemon not running. Skipping reload.

it looks like the user is not logged in (interactively) so the user systemd is not running, thus there's no daemon to tell to start the service

Can we tell home manager to wait for the user to log in before launching the sops service?

[becknik]

Can somebody explain why the home-manager module now symlinks to ~/.config/sops-nix instead of $XDG_RUNTIME_DIR since my last flake.lock update (I'm on 09f1bc8ba3277c0f052f7887ec92721501541938)?

This really confused me when searching for one secret today...

[Mic92]

@becknik this is because we cannot embed %r into configuration files when we want to link to secrets. However we can now XDG_CONFIG_HOME in advance. See the pull request that changed it: #530