Systemd.tmpfiles.settings tries to open default.nix file

{
  systemd.tmpfiles.settings = {
    "helix" = {
      "/root/.config/helix" = {
        "L+" = "/home/rocco/.config/helix";
      };
    };
  };
}

this is the module i made and imported in the configuration

        error: opening file '/home/rocco/.config/helix/default.nix': No such file or directory

why is it trying to open a default.nix file?

{
  systemd.tmpfiles.rules = [
    "L+ /root/.config/helix - - - - /home/rocco/.config/helix"
  ];
}

and why the hell is this (which should be the same) working?

Are you sure that’s your literal code? I’d expect that error if you were trying to use import.

This line is wrong. It should be something like "L+".argument = "/home/rocco/.config/helix";. The error you get is because systemd.tmpfiles.settings.<config-name>.<path>.<tmpfiles-type> is a submodule option. The module system sees paths for submodule types as something to import which should return the settings for the submodule. Instead, you can just set the submodule setting directly inline here.

1 Like

it is. the file is a module and is then imported in the configuration.nix

i’ve been trying to find the correct syntax for hours. Where did you get that info?

The options search page, as always, has this info.

https://search.nixos.org/options?channel=24.11&from=0&size=50&sort=relevance&type=packages&query=tmpfiles.settings

1 Like

i read it many times but could not understand it. like… The example uses d = {} and not “d” = {} and the argument field is not present. Also i could not understand those nix <name> fields.
Surely a skill issue but damn is there the need for a tutorial to read the docs hahahahha

For attribute names, strings can be used, but you can also use a literal valid nix identifier. So d and "d" are equivalent here. The docs for them live here: Syntax and semantics - Nix 2.28.1 Reference Manual

Understanding how to write literal attrsets is pretty important, they’re probably the most commonly used type in nix, so I’d recommend grokking that.

Yeah, those are unfortunately very poorly described. It should probably be something like:

systemd.tmpfiles.settings.<ruleName>.<path>.<ruleType>.user

systemd.tmpfiles is certainly among the most complex options, so don’t beat yourself up about it. nix.dev has a guide for the module system, as well as guides for the basic language, which might be helpful.

1 Like

thanks a lot it was a great answer :+1: … also this names thing is crazy. Why would anyone use that over what you wrote is nonsense to say the least and i would have never passed hours trying to understand. Maybe they are auto-generated and the algorithm is broken?

<name> is indicative of the use of types.attrsOf types.submodule (see the NixOS manual for more info), and yes it is autogenerated. Of course it could be improved!

2 Likes

In the original author’s defense, systemd.tmpfiles is an extreme outlier, it’s rare to have nesting at all.

Whoever wrote the module probably didn’t even consider this and just reused the existing types, and even if they did consider the docs with that much care, the effort to implement better anonymous attribute naming here just for a single module was probably more than they had spoons to do at the time.

The real issue is systemd-tmpfiles itself IMHO, there are few utilities with as poor configuration design as what the systemd folks cooked up here.

2 Likes

Yeah even the direct string syntax is awful, having to memorize a dozen columns and weird quoting syntax. As maybe “overkill” it might’ve been for systemd-tmpfiles to use the systemd ini syntax, it’d be a lot easier to read!

2 Likes