Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

home-manager issue during sops-nix.service startup #687

Open
nialov opened this issue Nov 29, 2024 · 0 comments
Open

home-manager issue during sops-nix.service startup #687

nialov opened this issue Nov 29, 2024 · 0 comments

Comments

@nialov
Copy link

nialov commented Nov 29, 2024

Problem

I am using sops-nix as a home-manager module on NixOS in WSL. The sops-nix.service fails during normal activation and nixos-rebuild with the following error message:

Nov 29 09:51:07 BL8W6G3 v95chg2b7d57pc7f08q7pym1h3bk3f8l-sops-nix-user[250104]: /nix/store/kvgassgqvfx8lqk12ramqdks59f3s3zc-sops-install-secrets-0.0.1/bin/sops-install-secrets: cannot update secrets symlink: rename /home/nialov/.config/sops-nix/.secrets3251914507/tmp.symlink /home/nialov/.config/sops-nix/secrets: file exists
Nov 29 09:51:07 BL8W6G3 systemd[2135]: sops-nix.service: Main process exited, code=exited, status=1/FAILURE
Nov 29 09:51:07 BL8W6G3 systemd[2135]: sops-nix.service: Failed with result 'exit-code'.
Nov 29 09:51:07 BL8W6G3 systemd[2135]: Failed to start sops-nix activation.

If I check the secrets directory after a failed activation, it has been created but has only one secret:

➜ ls /home/nialov/.config/sops-nix/secrets/
dragonsden_openai-api-key

So it seems the service tries to recreate the directory even after one secret has already been decrypted/symlinked?

Solution

While I was writing this issue I thought to check the specific secret that is created. I was configuring its name manually:

          dragonsden_openai-api-key = {
            name = "openai-api-key";
          };

Removing the manual naming made the service work again, almost. I had to add:

      systemd.user.services.sops-nix.Service.ExecStartPre = ''
        ${pkgs.coreutils}/bin/rm -rf ${config.sops.defaultSymlinkPath}
      '';

and the secrets were created (or rm -r the secrets dir myself). However, when I configured the name again, and used nixos-rebuild, I had no errors. Except until I rebooted. Then I had to disable the naming again to make the service succeed. So the naming seems to cause a problem that I believe is independent of my environment (WSL can cause many problems, but maybe not this one?), i.e. an error within sops-nix.

System info

I am using this on WSL where there is a known problem of the systemd user service not starting (nix-community/NixOS-WSL#375).

➜ nix flake metadata sops-nix
Resolved URL:  github:Mic92/sops-nix
Locked URL:    github:Mic92/sops-nix/3433ea14fbd9e6671d0ff0dd45ed15ee4c156ffa
Description:   Integrates sops into nixos
Path:          /nix/store/65n57z8maxfra6p41sk45ddpqm8dyadq-source
Revision:      3433ea14fbd9e6671d0ff0dd45ed15ee4c156ffa
Last modified: 2024-11-26 01:03:45
Inputs:
└───nixpkgs: github:NixOS/nixpkgs/c69a9bffbecde46b4b939465422ddc59493d3e4d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant