Change:
(n: v: (if v ? program then v else v // {program=n;})) wrappers); <del> securityWrapper = pkgs.stdenv.mkDerivation { name            = "security-wrapper"; phases          = [ "installPhase" "fixupPhase" ]; buildInputs     = [ pkgs.libcap pkgs.libcap_ng pkgs.linuxHeaders ]; hardeningEnable = [ "pie" ]; installPhase = '' mkdir -p $out/bin $CC -Wall -O2 -DWRAPPER_DIR="${parentWrapperDir}"  -lcap-ng -lcap ${./wrapper.c} -o $out/bin/security-wrapper ''; </del> <ins> securityWrapper = pkgs.callPackage ./wrapper.nix { inherit parentWrapperDir; </ins> }; ###### Activation script for the setcap wrappers

Discussion:
Describe the bug After update libcap from to error working capabilites. and Netdata configuration: Wrappers cat: Notify maintainers cc
If it's being denied by apparmor, it should say something along those lines in the kernel log. Are you actually running apparmor though?
The apparmor service is in use. Does not write an error in the logs. Disabling apparmor service doesn't fixed error: Worked with this patch:
Sorry, don't maintain neither netdata nor apparmor.
So basically apparmor 2.13.6 introduced this regression?
Sorry, wrong checked. Working with branch , with branch - not working - . Compare - Looking for a error further.
The diff between these versions is quite small I don't think that should be responsible.
Found. Working with rollback libcap to
In kernel 5.8 new capability - - Service netdata with add not working:
Problem with version . Step to reproduce Add to configuration: and running from user: In version 20.09 correct work, in master - bad work - .
cc libcap contributors -
Working with revert this commit - Need support new output of the program from to
Maybe also report the bug here, since you have a reproducible bug:
cc since the bug tracker seems to be unused.
This error is not reproducible in another distribution. Checked on ArchLinux - not reproduced.
The bug tracker is used. It is just the case that there are no open bugs right now. Please file a bug there if you believe libcap has a bug. Please include an example sufficient to reproduce it.
This error reproduced only NixOS. I can build a live-cd with this error. Can you use this variant?
Ok. Thanks. I think this is not a bug but rather an incompatibility regarding captotext output that changed.
The output format did become more compact in 2.41. This default output format also changed with the resurrection of meaningful support for in 2.29. That change is potentially more significant: Note: the official sources for libcap are here:
FWIW I would have suggested using the iab abstraction in libcap (introduced in libcap-2.33).

What you are trying to do would then look like this: capt working = capgetproc(); capiabt iab = capiabinit(); capiabfill(iab, CAPIABAMB, working, CAPPERMITTED); capiabsetproc(iab); capfree(iab); cap_free(working);
But how does one get the capabilities of a file without string parsing?
capt working = capget_file("/the/file/of/interest");
Perhaps I misunderstood? If you want to load the capabilities from a text string and not from the file-capabilities of the file itself: capt working = capfromtext("..."); That is, capt is libcap's abstraction for a capability set and you are trying to import them from somewhere. There is also a portable binary format capcopyext()/capcopyint(). However, there haven't been many users of this - the draft 1e spec intended it for things like tar and cpio to use.
We basically use both. Our setcap wrapper has capabilities set on its file and it will convert those to ambient capabilities at runtime. It seems that iab abstraction was not there when the original code was written. So there was no obvious way of using capt to set ambient capabilities.