nixos/qbittorrent: init

[fsnkty]

Description of changes

create a module to use qbittorrent as a service.

user notes

in ui settings changes

stateful service config management is possible, simply dont set serverConfig
setting serverConfig will still allow settings to be changed while the service runs but rebuilds, reboots etc will lose those changes that arent defined in serverConfig

password formatting

the password format that qbittorrent expects can be generated using this tool ( thanks Fea )
it can also be gotten from running the service independently and grabbing the formatted string out of the generated file after the setup phase

alternative UI's

custom webuis managed with nix are possible, examples with VueTorrent.

fetchzip to get VueTorrent from the source.

serverConfig.Preferences.WebUI = {
  AlternativeUIEnabled = true;
  RootFolder = "${pkgs.fetchzip {
    url = "https://github.com/VueTorrent/VueTorrent/releases/download/v2.7.2/vuetorrent.zip";
    hash = "sha256-bJyI7RvVCf0M5vs8Qi+uAHv74CWxSDZ0Bb6zWJ4x4CM=";
  }}";
};

from nixpkgs.

serverConfig.Preferences.WebUI.RootFolder = "${pkgs.vuetorrent}/share/vuetorrent";

use before merge example

assumes you have this (https://github.com/fsnkty/nixpkgs/tree/init-nixos-qbittorrent) branch as an input named qbit

{
  inputs,
  pkgs,
  ...
}:
{
  imports = [ "${inputs.qbit}/nixos/modules/services/torrent/qbittorrent.nix" ];
  services.qbittorrent = {
    enable = true;
    package = inputs.qbit.legacyPackages.${pkgs.system}.qbittorrent-nox;
    serverConfig.LegalNotice.Accepted = true;
  };
}

nice to haves / future PR ideas

• some way to generate the bizare password format used independently. (Thank you feathecutie!)
  • format conversion within the module (/on activation/ whatever else)
• gendeepINI
  • a more fitting type to use for this option.
  • output merging with stateful service config
  • handles migrationVersion in service config before hand

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

[camilosampedro]

@nu-nu-ko

I've added you to contributors here now that I've taken parts of your work in the tests and since you had added yourself to them in your branch I assume you're still keen to? let me know if not and ill remove of course.

If you are allowed, I'd like to be a contributor, thank you!

still unsure how to do assertions for options on other options so for now I've left it be

Do you mean during tests?

[camilosampedro]

I've seen this in deluge:

https://github.com/NixOS/nixpkgs/blob/nixos-23.11/nixos/modules/services/torrent/deluge.nix

When you use declarative = true, it tries to use the options that are required to be declarative, and if they are not set it errors:

The option `services.deluge.authFile' is used but not defined.

But it doesn't happen the other way, if authFile is declared and declarative = false

[camilosampedro]

Is it weird if there were two separate sets of options?

qbittorrent-nox
qbittorrent-nox-declarative?

[camilosampedro]

Also, related and unrelated. I was seeing that the web ui and other services were being unresponsive after a couple of hours.

I thought that the IO of qbittorrent was bringing the system down, but after 2 days of trying everything, it was my network device's firmware. 😅

I'll try to retest it this week.

[nevivurn]

Afaik, it is possible to pass in the webui and torrenting port via command line arguments, and I assume these arguments take precedence over other configuration options. This should let us implement openFirewall without forcing users to use the declarative config.

a better way to set CapabilityBoundingSet and SystemCallFilter to restrict all.

CapabilityBoundingSet is an allowlist, the strictest setting is just the empty string. Although, given that we 1) don't run qbittorrent as root, 2) set NoNewPrivileges, 3) don't set AmbientCapabilities, omitting it entirely is probably fine.

I personally think @system-service is a good enough default for SystemCallFilter.

I don't understand why it sets PrivateTmp to false

This comment in the upstream PR mentions adding torrents through the command line. Not sure if this is actually true.

ProtectSystem needs to be disabled if we aren't using declaritiveConfig

I don't think ProtectSystem should be enabled here. It will break users with per-category/torrent save paths, no matter what.

imo, we don't need lock down every option by default. Users that want to further harden their system can easily add these options in their own nixos configuration.

[nevivurn]

I don't see why we wouldn't set it regardless personally, leaving it empty seems to do nothing as according to systemd-analyze security qbittorrent on my system.

👍

I agree to some extent, id much rather every service does at least up to "breaks as little as possible"

I completely agree, we can enable everything that probably won't break users.

There are still a couple options left that I feel like are a tad bit too opinionated, namely

• non-default torrenting port
• umask 0066

[nevivurn]

an empty list isn't equivalent sooo 😅

Ah, did not realize the empty list wasn't doing anything. "" should work.

there is no default? its randomly selected from within a range from what i can tell. the non default web port is questionable.. but I think defaulting to 8080 is kinda dumb, happy to change it.

The bittorrent port is chosen randomly by default, and it is quite unexpected for nixos to fix an arbitrary port number by default. Similar with the web port, I don't see a reason for the NixOS module to deviate from the upstream default. With this module, it would be trivial for users to change it as needed, anyway.

umask 0066

how is this opinionated? in what case may this break something?

I think this would break users trying to access downloaded files without needing to run as the qbittorrent user, likely a common use case. Plus, if we're going for paranoid settings, why is it not 0077?

[undefined-landmark]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 287923 --package nixosTests.qbittorrent
Commit: f37d8847eab214634098ba75a499f8036a6ab287

---

x86_64-linux

✅ 1 test built:

• nixosTests.qbittorrent

[undefined-landmark]

Another friendly ping to @eclairevoyant and @zhaofengli. There are still requested changes from you. Please check if the changes are already implemented or still necessary. Thanks!

[andresilva]

I don't see any reason to hold this PR any longer and I will merge it soon unless someone raises any blocker. Any improvements can be done in follow up PRs.

[undefined-landmark]

Idk why you're pinging me when I don't have permission to dismiss my own requested changes...

Ah, I wasn't aware of that. My bad.

I don't see any reason to hold this PR any longer and I will merge it soon unless someone raises any blocker. Any improvements can be done in follow up PRs.

Great! Thanks.

[fsnkty]

I don't see any reason to hold this PR any longer and I will merge it soon unless someone raises any blocker. Any improvements can be done in follow up PRs.

I've squashed the commits, should be ready now, thank you.

[nixpkgs-ci]

Backport failed for release-25.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.05
git worktree add -d .worktree/backport-287923-to-release-25.05 origin/release-25.05
cd .worktree/backport-287923-to-release-25.05
git switch --create backport-287923-to-release-25.05
git cherry-pick -x 84d174e312870ccefb9ba0dd11532bb2a58773db

[Pandapip1]

This adds a module and should therefore not be backported IIUC

[eclairevoyant]

Why can't new modules be backported? It's not a breaking change.

Of course if we need to make some breaking changes to make it usable, that should be done first.

[undefined-landmark]

This adds a module and should therefore not be backported IIUC

From CONTRIBUTING.md:

The release branches should generally only receive backwards-compatible changes, both for the Nix expressions and derivations. Here are some examples of changes that are okay to backport:

✔️ New packages, modules and functions
✔️ Security fixes
✔️ Package version updates
    ✔️ Patch versions with fixes
    ✔️ Minor versions with new functionality, but no breaking changes

I believe this module should just work on 25.05. But will run the tests to make sure.

[Pandapip1]

Why can't new modules be backported? It's not a breaking change.

I seem to remember having a trivial module addition be denied on the basis that any change to the options is potentially breaking, but I can't find it nor can I find a reference to this being a precedent, so I guess it's probably fine.

[arunoruto]

For those who can't wait for the module to be backported, you can always import it from the unstable branch to your config. I am assuming you are using flake and have an unstable entry in the inputs:

nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable";

and you are passing the inputs to your config with specialArgs.

Then you can casually import the needed module:

imports = [
  "${inputs.nixpkgs-unstable.outPath}/nixos/modules/services/torrent/qbittorrent.nix"
];

The only problem could be that pkgs.vuetorrent is out of date for this config, but I highly doubt that.

When the time comes, you can just remove the imports entry for the qbittorrent.nix file and you are using the service from the "main" branch you configured.

[fsnkty]

The only problem could be that pkgs.vuetorrent is out of date for this config, but I highly doubt that.

you could also just grab pkgs.vuetorrent from unstable as well

to those wanting a backport, I'm not sure about the process there but if anyones willing to explain what (if anything) needs done to do so I'd be happy to. This has been in a working-enough state for quite some time so I'd assume itd be just fine

[eclairevoyant]

Literally just cherry-pick the commits on top of the release-25.05 branch (fixing merge conflicts) but it looks like there's already a PR: #429630

[kira-bruneau]

I noticed that qBittorrent.conf is created with mode = 1400. Why is the sticky bit set?

Also, it looks like permissions are ignored for symlinks anyway: https://www.man7.org/linux/man-pages/man5/tmpfiles.d.5.html#:~:text=L%2C%20L+%2C%20L?.

[fsnkty]

Why is the sticky bit set?

if my memory is right, setting it made qbittorrent unable to overwrite the symlink or otherwise within it with a directory/file.

it looks like permissions are ignored for symlinks anyway

if this is the case for the stickybit also then I'm not sure why I observed this behavior.

anyone willing to confirm qbittorrents behavior is consistent with/without this set, please do share.

[undefined-landmark]

A PR was made a couple days ago, changing this behavior. We could continue this discussion there: #482534.