Not searching for smartctl via PATH breaks NixOS

[vamega]

I run SnapRAID on Nixos, and I just noticed that snapraid has been throwing errors in my logs. It's been broken ever since bb3aae2, which introduced a hardcoded list of paths where it looks for the smartctl binary.

The problem on NixOS is that the actual location is only to be found in the nix store. The NixOS package for this does make smartctl available on the PATH as seen here, which stopped working when a hardcoded list of locations was introduced. If the commit message is to be taken at face value, perhaps it could only look for the hardcoded locations if a binary isn't found in PATH? Or maybe the other way?

For now on NixOS, I'm able to get snapraid to work by running it under a systemd service with a bind mount for smartctl like below.

  BindReadOnlyPaths = [
    "${pkgs.smartmontools}/bin/smartctl:/usr/bin/smartctl"
  ];

This however only works for a systemd service, and cannot work when running the binary as either `root or via sudo.

[amadvance]

This is intentional to improve security. The tools cannot be found using the PATH because they are run with root permissions.

What I can add is a new .conf option, like sys_smartctl, that will allow customizing the path used. This also applies to all the other tools, like bcachefs, zfs, and zpool.

[vamega]

I had thought it might have some security considerations. I’m not sure how a config file option will look yet, but will think about the implications. If it’s an application specific path like variable where the individual tools can be in different directories that’s easiest to support.

Individual options per tool can also work if that’s how you want to go about it (sys_{smartctl,zfs,bcachefs…})

Would it be possible to specify this via cli flags as well or only via a config file?

[amadvance]

Now I think a better approach is to have a new ./configure --with-smartctl=PATH option to allow for a specific path to be configured for smartctl. This would allow NixOS to provide a package linking directly to the correct dependency.

[vamega]

While that would work, that's not ideal in my mind. That would require a recompilation of snapraid very frequently since the path to the cli utilities becomes a build input. Having this be a path that's provided as a cli argument or a config file would avoid requiring the entire binary to be recompiled every time the smartctl/bcachefs/zfs location changes (which could be quite frequent I think).

This isn't breaking me right now, and I'm happy to experiment with this in a fork and get back to you. I can try to put aside some time to see how this would work on my own machine this weekend.

[vamega]

Oh, I see you already implemented it as a configure option in a recent commit.
Another issue with having to provide it as a build time option as I see it is it requires a separate compilation of the binary for each combination of tools. If we assume smartctl is required, this would require at least 4 binaries (base, bcachefs, zfs, bcachefs+zfs).

[amadvance]

I understand the downsides, but based on my understanding of NixOS, this is expected and intended behavior. These tools function similarly to external libraries. For instance, SnapRAID links to zlib and zstd, meaning a new SnapRAID binary is required for every new release of those dependencies.

Regarding the various optional dependencies, I assume the 'standard' SnapRAID package should include them all to ensure full feature support.

[vamega]

Sorry for the delay in responding.I think that runtime configurability would make packaging and deployment quite a bit smoother on systems like NixOS.

Some background on packing in Nix/NixOS

In Nix, compile-time options become part of the package identity, and different option combinations require different package builds. In this case, the selected options also affect the dependency closure size, since building a package with support for all filesystems would require installing things like btrfs-progs, ZFS userland tools, bcachefs-tools, smartmontools, etc.

Nix has a binary cache for prebuilt packages, but the central cache does not build every possible combination of options. When a user wants a combination that is not present in the cache, Nix falls back to compiling the package locally.

By making this a compile time option, users effectively need to choose between installing a larger dependency set for filesystems they may not even use, or triggering separate local builds on many user machines.

With runtime CLI arguments, distributions like Nixpkgs could instead provide a single cached SnapRAID binary, and only generate a very small wrapper script per system with the appropriate tool paths.

What I've tried so far

I do understand the implementation simplicity benefit of keeping this as a compile time option, especially since I’ve been experimenting with making it runtime configurable in a couple of branches.

Right now that branch supports specifying tool paths both via CLI arguments AND via the config file, and that definitely increased the implementation complexity. Doing this with only CLI arguments looks like it will be much less invasive.

One challenge was handling cases where the path is specified in both places and the values do not match. I settled on having the cli arguments supersede the values in the config file if both are present, which matches how I've seen a lot of tools work.

Another was that allowing tool paths inside the config file complicates config parsing itself. Either the config needs to be parsed in two passes, where the first pass discovers tool paths and the second uses them for probing, or the parsing model needs to change so the config is first parsed into an in-memory structure before any probing occurs.

I’m planning to experiment next with a CLI-only approach, since that avoids needing to restructure the config parsing logic.

I think reproducibility and auditability can still be preserved if SnapRAID logs the exact helper tool paths that were used during a run. This probably makes sense even if it's looking up the tool from the fixed list of paths.

[amadvance]

Can we use standard paths like --with-bcachefs=/run/current-system/sw/bin/bcachefs without making an explicit dependency?

Take care that at present the code rejects symlinks, but we can relax this requirement for explicitly defined paths.

But I would at least keep the direct dependency on smartctl, as it's really a strong dependency.

[vamega]

I don't think I'm clear about what you're saying. Are you saying we

I've got a version with the runtime tool arguments in this branch https://github.com/vamega/snapraid/tree/runtime-tool-config-cli-only. I'll try this out with a nixos module to utilize it this weekend, and make sure it works end to end.

What I have in that is a cli argument only approach, where the last value for an option is the one used. I plan to then have the nixos module have a wrapper script that provides the paths to the tools generated.

[vamega]

On my current nixos system, I found smartctl at /etc/profiles/per-user/root/bin/smartctl but bcachefs at /run/current-system/sw/bin/bcachefs

[vamega]

So I deployed the version in that branch, and it's worked last night.

It ends up generating a wrapper script with these contents:

❯ ls -lha /nix/store/ip989fy8hq5dfraagh9953kls61rhfbj-snapraid-15.0-unstable-2026-05-14/bin/
total 880K
dr-xr-xr-x 2 root root 4.0K Dec 31  1969 .
dr-xr-xr-x 4 root root 4.0K Dec 31  1969 ..
-r-xr-xr-x 2 root root  378 Dec 31  1969 snapraid
-r-xr-xr-x 2 root root 865K Dec 31  1969 .snapraid-wrapped

❯ cat /nix/store/ip989fy8hq5dfraagh9953kls61rhfbj-snapraid-15.0-unstable-2026-05-14/bin/snapraid
#! /nix/store/i27rhb3nr65rkrwz36bchkwmav6ggsmn-bash-5.3p9/bin/bash -e
exec -a "$0" "/nix/store/ip989fy8hq5dfraagh9953kls61rhfbj-snapraid-15.0-unstable-2026-05-14/bin/.snapraid-wrapped"  --smartctl-path /nix/store/lbc84cah417vbwki1wcga58jg277r5jd-smartmontools-7.5/bin/smartctl --bcachefs-path /nix/store/ndcls93nfgq81xzb763g7im7gaa39dqw-bcachefs-tools-1.38.0/bin/bcachefs "$@"

I used this to create a nix package for the snapraid package. If you're okay with this approach I'll try to submit a PR to the nixpkgs repo this weekend.

snapraid-unwrapped.nix

{
  lib,
  stdenv,
  fetchFromGitHub,
  autoreconfHook,
}:
stdenv.mkDerivation (finalAttrs: {
  pname = "snapraid-unwrapped";
  version = "15.0-unstable-2026-05-14";

  src = fetchFromGitHub {
    owner = "vamega";
    repo = "snapraid";
    rev = "af4ca597ca8d9021cd26f23115682254d022a517";
    hash = "sha256-9NAeJwMcsT7tU9h6KvlTUl/Isv9q9yxwWoSNxgDbJqg=";
  };

  env.VERSION = finalAttrs.version;

  doCheck = true;

  nativeBuildInputs = [
    autoreconfHook
  ];

  meta = {
    homepage = "http://www.snapraid.it/";
    downloadPage = "https://github.com/vamega/snapraid";
    changelog = "https://github.com/vamega/snapraid/blob/af4ca597ca8d9021cd26f23115682254d022a517/HISTORY";
    description = "Backup program for disk arrays";
    license = lib.licenses.gpl3Plus;
    maintainers = [lib.maintainers.makefu];
    platforms = lib.platforms.unix;
    mainProgram = "snapraid";
  };
})

snapraid.nix

{
  lib,
  stdenvNoCC,
  makeWrapper,
  snapraid-unwrapped,
  smartmontools,
  bcachefs-tools,
  zfs,
  withSmartmontools ? stdenvNoCC.hostPlatform.isLinux,
  withBcachefs ? false,
  withZfs ? false,
}: let
  runtimeToolFlags =
    lib.optionals withSmartmontools [
      "--smartctl-path"
      "${smartmontools}/bin/smartctl"
    ]
    ++ lib.optionals withBcachefs [
      "--bcachefs-path"
      "${bcachefs-tools}/bin/bcachefs"
    ]
    ++ lib.optionals withZfs [
      "--zfs-path"
      "${zfs}/bin/zfs"
      "--zpool-path"
      "${zfs}/bin/zpool"
    ];
  wrapperArgs =
    lib.concatMapStringsSep " "
    (flag: "--add-flags ${lib.escapeShellArg flag}")
    runtimeToolFlags;
in
  stdenvNoCC.mkDerivation {
    pname = "snapraid";
    inherit (snapraid-unwrapped) version;

    dontUnpack = true;

    nativeBuildInputs = [
      makeWrapper
    ];

    installPhase = ''
      runHook preInstall

      mkdir -p "$out"
      for path in ${snapraid-unwrapped}/*; do
        name="$(basename "$path")"
        if [ "$name" != bin ]; then
          ln -s "$path" "$out/$name"
        fi
      done

      mkdir -p "$out/bin"
      for program in ${snapraid-unwrapped}/bin/*; do
        ln -s "$program" "$out/bin/$(basename "$program")"
      done
      rm -f "$out/bin/snapraid"

      makeWrapper ${snapraid-unwrapped}/bin/snapraid "$out/bin/snapraid" ${wrapperArgs}

      runHook postInstall
    '';

    passthru.unwrapped = snapraid-unwrapped;

    meta =
      snapraid-unwrapped.meta
      // {
        mainProgram = "snapraid";
      };
  }

This was snapraid-unwrapped contains the C code, and can be cached in the nix binary cache. The wrapper script called snapraid will be generated and invoke the binary with the right CLI options. If any of the CLI tools snapraid wishes to call are changed, the wrapper is the only thing that needs to be regenerated. Also users can choose any combination of options in the wrapper, and only the wrapped script needs to be generated on the machine if there is no cache hit. That isn't problematic even on a tiny underpowered CPU.

I've run this alongside the code in my fork and it's working well. The logs point to the exact path of the tool that snapraid was invoked with.

If you're open to this approach, I'd be happy to open a PR to the nixpkgs repo.

[amadvance]

I understand that this can help NixOS, but having a runtime option that allows configuring the tools is a security risk. If an attacker finds a way to control the SnapRAID arguments, they can exploit it for privilege escalation. This is not possible with build-time options.

I was thinking instead of using the links that NixOS creates in /run/current-system/sw/bin/

Something like:

configureFlags = [
"--with-smartctl=/run/current-system/sw/bin/smartctl"
"--with-zfs=/run/current-system/sw/bin/zfs"
"--with-zpool=/run/current-system/sw/bin/zpool"
"--with-bcachefs=/run/current-system/sw/bin/bcachefs"
" --enable-symlink-tools"
];

[vamega]

What you propose is probably possible, the exact paths would need to be different though.
smartctl is at the very least at not in /run/current-system at least on my machine.

❯ which -a smartctl
/etc/profiles/per-user/root/bin/smartctl

I think I can see the problems allowing runtime paths for the cli arguments. If for example snapraid-daemon or some other tool allowed an options for specifying the CLI parameters, then the any such too could inadvertently provide root access.

I think that this is better handled by only having such a tool use the wrapper script and maybe having the wrapper only allow a single declaration for each parameter.

I don't think it's possible to prevent snapraid from executing arbitrary commands if the user already has elevated privileges. They could set up a bind mount like I've done to get snapraid to execute a command they control, but of course if they're able to set a mount namespace for snapraid to execute in I'd imagine they've already got too much access.

If you're certain you don't want to support cli flags, I'll submit a PR to nixpkgs to support build with CLI flags.