nixos/qui: init service

[undefined-landmark]

The qui packages has recently been merged to nixpkgs. In this PR a service module is created.

Like with the package the service module is quite similar to the autobrr module.

Appreciate any feedback.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[pta2002]

This looks mostly fine to me but I think it might interfere with QUI's ability to use external tools? I'd rather add an option for that. I'll check qui's docs and I'll give a proposal in a bit...

I say this because I've had this annoyance with Flood web UI where the NixOS module doesn't allow mediainfo to work by default. Would be nice if this works from the start here.

[pta2002]

Actually, nevermind this. I was misunderstanding the level of sandboxing this applies, turns out this should be fine.

I say LGTM. Further improvements can be made later!

[undefined-landmark]

Thanks for the quick review, and packaging qui. Just discovered that I forgot to set a default for the settings option. That's fixed now, and also checked with an additional test.

Not completely sure about the interference with external tools. It's possible to set the programs that are allowed to be executed via externalProgramAllowlist. Which is possible via this module.

The main issue I can think of is that an external programs needs to write files outside of StateDirectory, CacheDirectory, LogsDirectory etc. By setting ReadWritePaths it is still possible however. For "normal" usage I don't think this would be an issue.

[BatteredBunny]

Testing the feature i don't think it works at all right now. It starts whatever you give it with sh -c, and it complains about missing it. So i think bash should be added to the service PATH.

{"level":"error","error":"exec: \"sh\": executable file not found in $PATH","program":"test","hash":"007425713928ad60f0c76fd9692a6e136a99d676","command":"[sh -c /etc/profiles/per-user/user/bin/tmux]","time":"2025-12-30T14:56:54+02:00","message":"External program failed to start"}

My preference would be an option in the module to soften the hardening to allow it access to outside folders if the user desires it. Something like this:

      lessenHardening = mkOption {
        type = bool;
        default = false;
        description = "Allow external tools to write to files outside of the service.";
      };

I say LGTM. Further improvements can be made later!

but at same time i agree with this, i feel like this is extra functionality that can be improved on later, personally i dont think i would ever use this feature anyway.

On an unrelated note: i don't really like declaring the external tools via the qui GUI. Would be nice if we had an option to declare them in nix. If we had that option it would also simplify externalProgramAllowlist usage since it could be autofilled from whatever you declared in nix. e.g something like this:

externalTools = {
		my-notify-tool = writeShellApplication { # The path to this shell application would be added to externalProgramAllowlist and declared as an external tool
        	name = "my-notify-tool";
        	runtimeInputs = [
        		pkgs.ntfy
      		];
        	text = ``
         		ntfy publish mytopic "{hash} {name} sending info about torrent" # This template replacement part probably wouldn't work in this pseudo code example but you will get the general concept
        	``;
      };
};

As far as i can tell its not possible to declare external tools in config right now but can always be added to qui.

[undefined-landmark]

That's some useful info. I don't use the feature myself, so I didn't know all of this.

Will leave the module like this for the initial merge. If someone comes along that wants to use this feature, possibly me, I might look into it some more.

Wish you all a happy new year!

[undefined-landmark]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 472934 --package nixosTests.qui
Commit: 8e8158f95dcb4f3f2f892f1bec744bc6386e255b

---

x86_64-linux

✅ 1 test built:

• nixosTests.qui

[undefined-landmark]

Thanks for your review @BatteredBunny. Just pushed a commit that includes your proposed changes.

Any input on the use, and potential issues, of DynamicUser for this service? See this comment for some more info: #472934 (comment).

[undefined-landmark]

As discussed in the comment thread the current state of the module is enough for the initial merge. Even though there are some rough edges when trying to run external programs.

In a future PR we could look into improving support for the external programs functionality.

[undefined-landmark]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 472934 --package nixosTests.qui
Commit: 28bb1c7f34f9b61958cacf1b5fad1c303ff0507b

---

x86_64-linux

✅ 1 test built:

• nixosTests.qui

[undefined-landmark]

The newest qui release also has hardlink support. Will need to rework the service a bit to allow for hardlinking.

For hardlinking to work, the service needs rw permissions on the downloaded files. With DynamicUser = true this is difficult because of the implied ProtectSystem=strict. This makes the download folder readonly in most cases, I assume.

Will do the following:

• Remove DynamicUser
• Add option for user/group so the service can get the right permissions for the downloaded files
• Add hardening options to compensate for removing DynamicUser

[undefined-landmark]

Will do the following:

* Remove `DynamicUser`

* Add option for user/group so the service can get the right permissions for the downloaded files

* Add hardening options to compensate for removing `DynamicUser`

These changes are implemented. Largely reused the hardening settings that are used for nemorosa (#462968). For that service the hardlinks are working. However there I did set Umask = 0002 so the torrent client can download to the linking directory. As for this service cross-seeding is not the main point, I think we could leave this for the user to set.

Personally I don't use the cross-seeding functionality so I can't check it 100%. If the sandboxing turns out to be too tight it can always be relaxed later. Basic functionality is there at the moment.

[undefined-landmark]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 472934 --package nixosTests.qui
Commit: ba32dedce4fea8122148b562680c376571d471b7

---

x86_64-linux

✅ 1 test built:

• nixosTests.qui